Хорошее MVC

[Psycho Tiger]

Имеется в виду так?

Нет, имеется ввиду определение этих констант в наследнике Event.

[Котяра]

Так принято. Не надо подписчику иметь импорт диспетчера (если ты там определяешь константы)

[fish_r]

@Котяра, @_etc. Почитал, подумал... вы совершенно правы. Спасибо.

[etc]

Ах да, я забыл, ещё такие события не всегда отсылает единственный диспетчер.

[fish_r]

Сообщение от etc

Ах да, я забыл, ещё такие события не всегда отсылает единственный диспетчер.

Вот насчет этого я хотел бы уточнить. Как на твой, несомненно более опытный взгляд, если в качестве диспетчера таких событий использовать специально для этого созданный объект (естессно расширяющий EventDispatcher)? Видимый глобально он мог бы сделать доступными сигналы объектов не находящихся в прямой или глобальной видимости. Но, тогда не наступит хаос в программе? Не слишком ли это сильное
разделение связей между объектами? Вроде бы так вообще легко потерять контроль над взаимосвязями объектов в программе.

[etc]

Глобальный — зло. Через него кто хочет и как хочет шлёт, в итоге отледить, что и откуда, невозможно.

[Котяра]

Но многие таки используют. См. Spring и EventBus.

[HardCoder]

Здравствуйте. Если подобное уже здесь обсуждалось, приношу извинения, ибо после 10 страниц чтения топика - перестал понимать о чем идет речь.
И так вопрос. Контроллер обработал некую информацию. В соответствии с этой информацией нужно провести изменения в представлении. Но дело в том, что эти изменения модели не касаются. Что делать? Напрашиваются такие варианты:
1. В контроллере есть же ссылка на представление, значит мы можем вызвать метод этой вьюшки прямо из контроллера. Но речь идет об "Хорошее MVC", согласно которому контроллер не должен изменять представление.
2. Через модель диспатчить событие, и ловить його в представлении. С точки зрения MVC - это хорошо, но с точки зрения программирования - корове седло. Зачем лишний посредник (модель) в этом случае?
Как грамотнее поступить?

[Dukobpa3]

То что контроллер обрабатывает информаию уже не совсем академический мвц. Логика должна быть в модели если так чтоб совсем правильно.
Но у меня тоже мозг в контроллере

И если контроллер обрабатывает нечто что важно для вью - значит нужно это нечто выносить в модель, а дальше уже модель по накатанной схеме диспатчит что мол: "я поменялась отрендерись там" во вьюху.

Это если в общем, хотя ситуации разные бывают. Лучше конкретный пример приведи.

[HardCoder]

Конкретный пример: Игра, изометрический плиточный мир, разные юниты в этом мире... Это все в контейнере - вьюхе. Контролер получает известие от одного юнита, что этот юнит переместился на другую плитку. Значит надо передать вьюхе что нужно отсортировать экранные обьекты. В модели есть массив этих экранных обьектов. Но в ней нигде нет информации на каком уровне глубины в дисплей-листе эти обьекты расположены. Значит в модели нечего менять, так как ей до фонаря как эти обьекты расположены по глубинам, на ход игры это не влияет. Контроллеру тоже до фонаря - его интересуют лишь x, y и пр. свойства. Единственный кому не наплевать - это представление, так как оно беспокоется о том чтобы пользователь правильно воспринимал происходящее.

Добавлено через 3 минуты

Сообщение от Dukobpa3

То что контроллер обрабатывает информаию уже не совсем академический мвц. Логика должна быть в модели если так чтоб совсем правильно.

Но если модель будет и хранить данные и обрабатывать их - зачем тогда нужен вообще контролер? Просто чтобы быть ненужным посредником между моделью и вьюхой?