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

[Universe]

Возник вопрос следующего плана. Есть у меня кнопка с кучей эффектов и текстовых слоёв, которые по сути отображают одну и туже надпись, один слой допустим является маской, другой ещё чем то и т.д. Так вот, мне нужно как то одним махом все эти текстовые поля менять, т.е. изменил переменную в родителе - все текстовые поля изменились. Как я могу это сделать?:)

[goodguy]

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

[Wolsh]

Фильмы про войну смотрели? Солдатик из окопа весь в замерзшем бинокле телеграфирует штабу - "вижу врага по левому флангу на десять часов!" Это Событие.
Из Штаба ему приходит ответ "Затаиться и пристрелить!" И это - команда.
Довольно нелепо, когда из штаба приходит событие "вижу врага слева". Солдатику остается чесать репу, не зная что делать. Ну а про приказы штабу от солдатиков из окопа думаю итак все понятно.

[Universe]

ну не обязательно событие, это то что сразу в голову пришло! Мне надо чтобы все объекты определённого типа ориентировались на одну переменную и меняли своё значение автоматически при изменении этой переменной! Если говорить терминами вашего примера Wolsh, то мне нужно следующее: Командир отряда кричит "В АТАКУ!" и все солдаты бегут за ним в нападение. Он же не будет к каждому подходить и кричать "ПОБЕЖАЛИ"!
И я вот думаю, может мне поможет статическая переменная в главном классе, ссылка на которую есть в каждом нужном мне объекте? Или что-то ещё предложите?

[КорДум]

Сделать нужно сеттер, в сеттере вызывать методы у КАЖДОГО нужного объекта. Wolsh все правильно сказал. Иначе расстрел за быдлокодерство ;)

[Universe]

т.е. полюбому обращаться к каждому нужному объекту из родителя?

[КорДум]

Хорошая архитектура это подразумевает. Но никто Вас не заставляет ее возводить ;)

[Wolsh]

Universe, просто дело технически в том, что переменная переменной, допустим Вы такую создали, и что теперь, каждый солдатик должен 30 раз в секунду звонить в штаб и спрашивать - "Побежали? Или сидим дальше?"
Команда кричится один раз, но, если уж Вы настаиваете на реалистичности примера ;), по законам физики долетает в уши солдатиков она по-порядку их расположения в окопе. Так что цикл и не парьтесь.

[alatar]

Можно каждому солдату дать рацию (диспатчер). И орать только в рацию (послать событие в диспатчер).

[КорДум]

Можно каждому солдату дать рацию (диспатчер). И орать только в рацию (послать событие в диспатчер).
Я выделил нужное слово. То есть, от этого не уйти.

[Wolsh]

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

[alatar]

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

[Wolsh]

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

[Universe]

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

[2Sun]

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

[Universe]

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

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

Добавлено через 1 минуту
Как то всЁ на разговоры про войну свалилось.
Скоро теорию ООП начнут на примере приготовления курицы-гриль объяснять.
Куда все катицо...
Ну про курицу гриль это вы погорячились!))) Это скорее на каком то форуме домохозяек можно было бы такое встретить))

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

[alatar]

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

[Wolsh]

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

[expl]

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

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

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

[Wolsh]

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