Хорошее MVC

[etc]

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

Да, конечно. Это пример написанный наспех. Контроллер может воспринимать Main как просто DOC, но мне все равно не нравится - не должен объект сам себя куда-то добавлять.

Кто куда кого добавляет? DOC, да, это логичнее.

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

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

  [Event( name="some event" type="com.somepack.SomeClass" )]

Мне удобнее традиционным способом - видно перечень констант в панели Outline.

И [Event()] тоже, как раз в аутлайне и появится (это в FB во всяком случае). Тигра выше написал, что имелось ввиду.

[fish_r]

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

Кто куда кого добавляет?

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

Оба варианта мне не нравятся, потому, что контроллер должен иметь дело с сигналами объектов, а не с манипуляцией объектами.

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

И [Event()] тоже, как раз в аутлайне и появится (это в FB во всяком случае). Тигра выше написал, что имелось ввиду.

Создание объекта расширяющего Event, с определением перечня каст. набора событий -
в результате мы получаем возможность подписываться на события инициализируемые другим объектом, даже не находящимся в области видимости подписчика? Это имеется в виду?

[etc]

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

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

Оба варианта мне не нравятся, потому, что контроллер должен иметь дело с сигналами объектов, а не с манипуляцией объектами.

По мне так контроллер на то и контроллер, чтобы манипулировать.

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

Создание объекта расширяющего Event, с определением перечня каст. набора событий -
в результате мы получаем возможность подписываться на события инициализируемые другим объектом, даже не находящимся в области видимости подписчика? Это имеется в виду?

Нет, имелась ввиду лишь первая часть про создание кастомного события. Остальная часть за гранью понимания.

[fish_r]

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

Нет, имелась ввиду лишь первая часть про создание кастомного события

Ну, а в чём бонус то? В этом случае.

[Котяра]

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

[etc]

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

Ну, а в чём бонус то? В этом случае.

В том, что мы не тащим за собой конкретный класс-вещатель при подписке на такие события, в том, что мы заведомо знаем тип приходящего события (указывая оный в обработчике), в том, что будет корректно работать автокомплит (большинство IDE построено именно на такой схеме объявления событий), а также в том, что в автокомплите будут перечислены именно типы событий, а не всё статическое барахло диспетчера.

[fish_r]

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

[etc]

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

[fish_r]

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

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

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

[etc]

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