Продиспачить событие в детей

[Wolsh]

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

[expl]

Не понимаю, почему система

child ---call of method--> parent
      <----event----------

не имеет права на жизнь.
Да, централизация рулит, да, она позволяет детям не знать о родителе,
но ведь она приводит к чудовищной логике в родителе, который слишком много на себя берет.
Неужели децентрализация рулит меньше?

[alatar]

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

[Wolsh]

Не совсем. Это другой способ реализации другой задачи, описание которой следует за "они могут". Тем не менее суть остается той же самой, сложности эти разные окопы и полки не добавляют сверх того, что добавят при использовании событийной модели – ссылки то для подписки придется также протягивать во все щели. Названия разные, а способ один – вызов метода в каждом экземпляре списка.

[Universe]

эм...про рацию не понял!

[2Sun]

Как то всЁ на разговоры про войну свалилось.
Скоро теорию ООП начнут на примере приготовления курицы-гриль объяснять.
Куда все катицо...

[Universe]

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

ха, этот пример с солдатиками становится забавным. Прям флеш-стратегия!)))

Не совсем. Это другой способ реализации другой задачи, описание которой следует за "они могут". Тем не менее суть остается той же самой, сложности эти разные окопы и полки не добавляют сверх того, что добавят при использовании событийной модели – ссылки то для подписки придется также протягивать во все щели. Названия разные, а способ один – вызов метода в каждом экземпляре списка.

а что вы понимаете под "тянуть во все щели"? К счастью для нас солдатики во флеше могут быть дубликатами одного класса, следовательно написав подписку единожды в этом классе все его экземпляры будут уже знать какого папку им слушать!

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

Как то всЁ на разговоры про войну свалилось.
Скоро теорию ООП начнут на примере приготовления курицы-гриль объяснять.
Куда все катицо...

Ну про курицу гриль это вы погорячились!))) Это скорее на каком то форуме домохозяек можно было бы такое встретить))

Добавлено через 2 минуты
хотя с другой стороны - какая разница на примере чего объяснять, главное чтобы понятно всем было!

[alatar]

эм...про рацию не понял!

При создании, каждому экземпляру класса, который должен реагировать на определенное событие, передается ссылка на экземпляр EventDispatcher (всем на один и тот же экземпляр). Эти классы подписываются у него на событие. После чего в этот диспатчер, класс сообщающий об изменениях (у него тоже должна быть ссылка на этот диспатчер) диспатчит событие.

[Wolsh]

а что вы понимаете под "тянуть во все щели"? ... написав подписку единожды в этом классе все его экземпляры будут уже знать какого папку им слушать!

Ответ то был не Вам, и не про ваших "солдатиков" одного класса, а про войска alatar'a, у которого много разных полков. Если Вы не заметили, разноклассовость и разнородительность были его аргументом в пользу Событий. Вы же опять поняли все наоборот)) Я устал спорить, если честно - я предельно ясно свою позицию описал, хотите делать сильную связность - пожалуйста, дайте всем позывной штаба в статическую константу и пусть подписываются и слушают. Давайте доведем этот организм до такого расстройства, когда мозг будет информировать о своем состоянии пальцы, а пальцы - командовать мозгом.

[Wolsh]

Во-первых, это обычная логика, что и заложено собственно в ООП. Данная схема ее переворачивает. По логике вещей, предназначение детей знает тот, кто их народил. Он создавал эти экземпляры с известной ему целью. Само слово "родитель" не обязано означать контейнер, в котором непосредственно лежит экземпляр. Родитель это тот, кто его инициализировал и "бросил на поле боя". Поэтому именно у него права управления, у него логика. Логика будет чудовищной, если ее не распределить правильно. Никто же не заставляет вас описывать в Мейне смену стейтов каждой кнопки при наведении мыши. Надо правильно провести абстракцию, чтобы каждый занимался своим делом и знал его хорошо. Брал на себя ровно столько, сколько может сделать сам, обеспечивал свой жизненный цикл и управлял своими составляющими. Здесь невозможно делать наполовину правильно или на 75% логично. Надо стремиться к четкой иерархии. Если вы добавляете в класс ссылку на родителя, это «сильная связность». То есть вы не сможете использовать этот класс отдельно в другом проекте. Этот класс получил недостаточную абстракцию, он не самодостаточен, не может жить и работать отдельно от класса родителя установленного образца. Дети начинают требовать наличия определенных свойств у родителей, что противоречит всякой логике.
Конкретно о цепочке. Предположим, что она хороша. Тогда давайте использовать ее везде. Что мы получим? Всякие сеттеры типа width, height, rotation теряют свой смысл, ведь это некошерный прямой доступ к свойствам ребенка, больше он нам не нужен, у нас есть отличная система событий! Давайте подпишем ребенка на События от родителя - Event.SET_WIDTH, Event.SET_HEIGHT. Маразм? Но это ровно то, что вы предлагаете.

this.addEventListener(Event.SET_WIDTH, child.newWidthHandler);

Родитель знает своих детей, он их создал в своем теле. Дети не знают своих родителей (parent не в счет, это ссылка на контейнер, а не на родителя). AS3 устроен изначально по концепциям ООП. Родители знают свойства и методы своих детей, они импортировали их классы)). Они могут вызывать нужные методы напрямую, child.width = 5, без всех этих странных цепочек с созданием и распространением Событий. Дети же – наоборот, не знают кто их создал и кто ими управляет, это дает свободу создавать эти экземпляры в разных проектах разными родителями, использовать классы повторно, расширяя при необходимости, безо всякой сильной связности с родителем. Родитель не должен обладать какими-то особыми публичными методами для работы с этими экземплярами. Он может быть таким, как нужно данному проекту. Ваше решение использовать данный модуль в своем приложении не требует от вас переделки всего приложения ради этого модуля из-за того, что он требует от классов выше каких-то особых точек доступа, за которые он собирается их дергать, вмешиваясь в их работу. Такой модуль должен только информировать вышестоящих, но никак не управлять ими. Вышестоящие решат, что делать или не делать с этой информацией. Это и есть иерархия. Это – правильная и логичная цепочка связи.