|
|
|||||
По мне, так если у тебя есть набор статических констант - это классический случай, когда по любому их надо прятать в отдельный класс, как-нибудь его тематически-обобщенно обзывая, чтобы места не занимали и беспорядок не наводили.
__________________
while(live()) { hope(); } |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
ZergMaster, само собой. Так и сделано. Есть пакет data, в котором живёт класс, например, CharacterIDs. Но в него лезут как классы Модели, так и Вью. Мой вопрос, является ли использование общих ID-шников Моделью и Вью нарушением принципа взаимной независимости элементов MVC?
__________________
Не сломано - не чини! |
|
|||||
Lorem ipsum
|
Да какая же тут может быть зависимость?! Если все в курсе, какие общие термины используются в приложении, доступ к механизмам они от этого автоматически не получают.
__________________
Поймай яблоко 2! |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Zebestov, спасибо. Понял-отстал.
__________________
Не сломано - не чини! |
|
|||||
Lorem ipsum
|
Нене, ты не отставай, спрашивай ) я сам поначалу заморачивался по каждому поводу.
__________________
Поймай яблоко 2! |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Друзья! В соседней теме обсуждали, как asset-ы для игры загружать. Пока у меня для этого в AssetManager-е есть Dictionary, где хранятся и отдаются по строковым ID BitmapData графики: для главного героя (ГГ), локаций, врагов и т.п. Соответственно, пачки картинок должны загружаться или удаляться в определённые моменты. В частности, картинки для ГГ - при выходе из интерфейса создания своего персонажа, картинки для локации - момент захода в локацию и т.п.
Вопрос №1, кто в MVC командует этим процессом и дёргает паблики Asset-менеджера? Например, текущая локация у меня - это свойство ГГ (экземпляр Character). Если игрок выбирает опцию "сменить локацию" и попадает в другую, в модели персонажа свойству _location присваивается новое значение. Тут же по идее должно отправляться событие, по которому нужно давать отмашку Asset-менеджеру грузить картинки. Вопрос, кто должен ловить это событие: сам Character, Модель, Вью? Вопрос №2 в продолжение. Если картинки ГГ должны загружаться сразу после создания персонажа (и оставаться в быстром доступе до самого конца игры), то я решил сделать на будущее пакет heroCreation и какой-нибудь примитивный класс, который потом будет реализовывать полноценный процесс создания ГГ для игрока. И вот о чём я задумался. По уму для создания ГГ должна быть своя триада MVC. Значит, кто-то должен её создать. А у меня это сделать некому. Подскажите, как должны выглядеть Модель, Вью и Контроллер самого верхнего уровня? Я так понимаю, в данном вопросе вариантов немного, есть некий канонический вид. Спасибо.
__________________
Не сломано - не чини! |
|
|||||
странный вопрос.. событие оно на то и событие, что поймать его могут все, у кого есть экземпляр. А могут не ловить. В том плане, что кому надо, тот и должен. Насколько я понимаю, в данном случае модель чарактера, которую уже слушает вью чарактера.
это как? 0_о
__________________
while(live()) { hope(); } |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
Кстати, даже до события можно. Если игрок выбирает опцию "сменить локацию", но об этом первым "узнаёт" Вью, потом Контроллер. Возможно, кто-то из них уже может скомандовать asset-менеджеру начинать загрузку с диска? Цитата:
public function Battle(host: MainView, player:Character, enemy:Character, location:Locations):void { _host = host; var foregroundCharactes: Vector.<Character> = new Vector.<Character>; foregroundCharactes.push(player); foregroundCharactes.push(enemy); _model = new BattleModel (foregroundCharactes, location); _view = new BattleView (_model, _host); _host.addChild(_view); _view.addEventListener(ViewEventsIDs.MENU_SELECT, menuCommandHandler); // Подписываемся на выбор меню _view.addEventListener(ViewEventsIDs.INSTRUCTIONS_LOADED, ClearInstructionsArray); // Событие обработки массива состояний _model.init(); } Добавлено через 3 часа 29 минут Скажите, а прочитавшим эту тему от корки до корки ачивку на форуме дают?
__________________
Не сломано - не чини! |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
В плане оффтопика скажу, что получил искреннее удовольствие от чтения той самой темы. Интересно было наблюдать, как нынешние гуру, каждое слово которых моментально отливается в граните, каких-то 6-8 лет назад мечутся и дискутируют на предмет удачных (а по факту зачастую и неудачных) подходов. В частности, Psycho Tiger или Zebestov, проходящий путь от Контроллера к Модели...
Закончил с лирикой, конкретизирую вопросы. Люди, по всей видимости, тут уже шарахаются, видя много текста от меня. Дам вместо него ссылку. Гляньте плиз вот это сообщение, оно как раз по моей теме. Я правильно понимаю, что то, что советовали для реализации дочерних Контроллеров/Моделей - это "второй вариант"? У меня в голове как-то плохо умещается взаимодействие элементов триады MVC, если каждый из них САМ создаёт своих дочек. Правильно я последовательность себе представляю: 1. Главный Вью создаёт дочерний Вью. В главном пишем геттер для дочернего. В дочернем пишем сеттер для дочерней Модели. 2. Главная Модель создаёт дочернюю Модель и к ней также геттер. 3. Главный Контроллер из главного Вью забирает по геттеру дочерний Вью, а также из главной Модели ссылку на дочернюю Модель и создаёт дочерний Контроллер, передавая в его конструктор ссылки на дочерние Модель и Вью. Дочернему контроллеру есть на что подписываться (связка "V-C") и чем командовать (связка "C-M"). 3. Наконец, дочерний Контроллер, уже имея ссылку на дочернюю Модель, просто устанавливает её для дочернего Вью через сеттер. Дочерний Вью подписывается на дочернюю Модель, "закрываю" последнюю связку "M-V". Всё готово. Всё верно или я опять перемудрил? И не будет ли косяков, связанных с очерёдностью создания дочерних элементов в таком порядке? И в какой DOC должен быть добавлен дочерний Вью? И ещё вопрос. Нормально, когда Модель вообще одна, а разные Контроллеры появляются в комплекте с разными Вью по необходимости?
__________________
Не сломано - не чини! |
Часовой пояс GMT +4, время: 11:02. |
|
« Предыдущая тема | Следующая тема » |
Теги |
MVC , mvo , Проектирование |
|
|