Хорошее MVC

[fish_r]

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

Controller в принципе не должен знать, что такое Main.

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

Константы имён событий надо объявлять в самих событиях.

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

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

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

[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 построено именно на такой схеме объявления событий), а также в том, что в автокомплите будут перечислены именно типы событий, а не всё статическое барахло диспетчера.