Взаимодействие двух классов представления.

[dendead]

Доброго времени суток. Возник такой вопрос... Есть два класса, один из которых представляет героя игры, а именно его отображение:

public class HeroView extends Sprite {
public function HerowView( ) {
// код конструктора
}
}

А второй отображает предметы магазине и остальной интерфейс игры:
public class InterfaceView extends Sprite {
public function InterfaceView( ) {
// код конструктора
}
}

Так вот, как наиболее простым способом взаимодействовать между этими классами, если они оба являются классами представления.

Можно написать весь код в одном классе, тогда проблем не возникнет, но есть же ещё варианты?

Наверное нужно читать MVC...

[Akopalipsis]

Наверное нужно читать MVC...
Да, при чем не один день.. На форуме посмотрите в разделе "статьи", и поищите поиском по этому разделу "mvc". В последних темах так же есть ссылки на книги. Месяц чтения с утра до ночи Вам обеспечен :)

[dendead]

По книжке Мука имею общее представление о MVC, но сейчас запутался в своём же коде.

[shmaser]

Паттерн Mediator вполне решил бы проблему связывания объектов одного уровня в отношении "многие ко многим".
http://ru.wikipedia.org/wiki/Посредник_(шаблон_проектирования))

[Dukobpa3]

Медиатор (http://www.flasher.ru/forum/blog.php?b=674), то оно конечно да.
Но только не могу сказать, что герой и магазин - это объекты одного уровня.
Можно чуть больше подробностей? Какие задачи у героя. Что такое герой в данном контексте. Что такое магазин в данном контексте?

[Isfet]

скорее всего должны общаться контроллеры героя и магазина.

[dendead]

Игра представляет из себя подобие тамагочи. В классе "герой" находится код для отображения питомца. Добавление частей тела с помощью addChild и и слушатели событий на действия игрока. В классе "интерфейс" находятся продукты, которыми можно покормить героя и элементы интерфейса (окна, панели и т.д.). Здесь также использую addChild для добавления объектов на сцену и некоторые слушатели для реакции на действия.

[Dukobpa3]

В целом питомец и магазин это совсем разные модули.
Если говорить об мвц то питомец это будет свой контроллер-модель-вью. магазин - своя такая же триада.

Но например контроллер магазина может иметь доступ к модели питомца.
Мы купили в магазине нечто, оно сразу попало в модель питомца, модель питомца сообщила об этом. Вью питомца услышала это сообщение и перерисовалась.

Смешивать два логически разных модуля в один не ок.

[shmaser]

Dukobpa3,
Но только не могу сказать, что герой и магазин - это объекты одного уровня.
Можно чуть больше подробностей? Какие задачи у героя. Что такое герой в данном контексте. Что такое магазин в данном контексте? Автор указал именно вьюшки героя и магазина. В вашей же статье:
Если брать ближе к флешу, то медиатор часто используют именно со стороны вью.
В медиаторе инкапсулируют несколько вьюх. Медиатор является посредником в общении между этими вью. Каждая из вью видит только свой медиатор, и может отдать/получить данные в/из него.
содержится ответ на вопрос автора:
как наиболее простым способом взаимодействовать между этими классами, если они оба являются классами представления?

[dendead]

У меня основная сложность с классом контроллера. Дальше всё более менее понятно. Например в модели вызывается dispatchEvent, а в вью слушатель принимает этот вызов и рисует отображаемый объект. Что в данном случае должно находится в контроллере?

[Dukobpa3]

Если бы это были вьюшки трех врагов - без проблем мог бы быть медиатор.
А магазин и герой слишком разные для того чтоб пихать в один медиатор.
Никто не запрещает, но этот код будет слегка попахивать.

Медиатор лучше использовать как менеджер однотипных либо одноуровневых объектов.
Если в игре кроме героя и магазина ничего нету - без проблем можно считать что они находятся на одном уровне.
Если магазин - это окно, одно из многих, и у нас будет еще пачка функционала - медиатор слегка неуместен.

[Babylon]

"Вью слушатель" это действительно ближе к медиатору. Чистый вью ничего не слушает, а лишь принимает данные от сервиса в соответствующем хэндлере контроллера.