addChild не используя DO наглядно.

[alatar]

expl, может развернете свою мысль? Мне высказывания Wolsh вполне понятны. А вот вашу мысль я как-то не уловил.

[expl]

Моя мысль проста:
"IEventDispatcher есть, а IDisplayObject нет, зато можно сделать интерфейс с медодом get displayObject() : DisplayObject и это замечательно"

[Psycho Tiger]

А мне это совсем понятно.
Что такое DisplayObject? Объект, который можно добавить в дисплай-лист и визуализировать средствами рендера у флеш плеера.
Любой DisplayObject это IDisplayObject. Но и любой IDisplayObject это DisplayObject. Зачем делать интерфейс? Незачем. Он лишний. Только чтобы в исключительной ситуации наследовать интерфейсы, вместо использования "as".

[alatar]

Тогда уже toDisplayObject() : DisplayObject.
Насчет "замечательно" — сомнительно, т.к. дает возможность легко сломать компонент (например по незнанию или по неосторожности). Придется как в spark контейнерах перекрывать addChild / removeChild и т.д., в случаях если используются собственные методы добавления детей.

[Wolsh]

Так вся проблема чисто в потоке сознания. Именно в сознании программиста IComponent является DisplayObject. Программист считает этот интерфейс расширением ДО. Именно поэтому принимает IComponent и, ничуть не сомневаясь, на автомате пишет addChild(). Потому что для него компонент – несомненно ДО, и никак иначе. Это и есть суть маркера. Но компилятор не обладает такой верой, и кричит "А позвольте-ка! Что это вы мне тут подсовываете?" Ну так если Вы так уверены, что компонент всегда будет ДО, что мешает использовать кастинг? Сомневаетесь в себе – используйте более точную архитектуру.
Так что я с кем... в идеале я за минимум маркеров и приведений, но и конструкции, возвращающие аватары экземпляра мне не по душе, ибо костыль. Реально проблема кроется выше в генофонде, в косяках с построением наследования компонентов, я думаю. Надо там копать. Проектировать надо, а не писать как фишка ляжет и потом искать в написанном архитектурные решения. Надо изначально понимать, о чем вообще интерфейсы, а о чем – классы. Если над экземпляром будут совершаться действия и надо гарантировать, что над ним такие действия возможны – это не входит в круг обязанностей интерфейса. Интерфейс говорит "ЯМогуПожаритьКартошку", но никак не "МеняМожноЖаритьКакКартошку".
Впрочем, с такими методами как IComponent#addAsChildTo(this) я уже ничему не удивляюсь...
"картошка.жарься(печка)" вместо печка.пожарь(картошка).
Приятная беседа получилась

[expl]

Сообщение от Psycho Tiger

А мне это совсем понятно.
Что такое DisplayObject? Объект, который можно добавить в дисплай-лист и визуализировать средствами рендера у флеш плеера.
Любой DisplayObject это IDisplayObject. Но и любой IDisplayObject это DisplayObject. Зачем делать интерфейс? Незачем. Он лишний. Только чтобы в исключительной ситуации наследовать интерфейсы, вместо использования "as".

Теперь понял.
отсутсвтие интерфейса - это такая защита от попыток "имплементировать" нативные функции.

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

Насчет "замечательно" — сомнительно, т.к. дает возможность легко сломать компонент (например по незнанию или по неосторожности). Придется как в spark контейнерах перекрывать addChild / removeChild и т.д., в случаях если используются собственные методы добавления детей.

Никто не говорил, что оно идеальное. Все как всегда зависит от конкретной ситуации.

Именно в сознании программиста IComponent является DisplayObject

Не хотите - не расширяйте. Просто делаем компонент - не дисплей-объект и у него поле displayObject, которое добавляем. Или отодрать displayObject от компонента? Да ну, это какой-то уожос получается.

Интерфейс говорит "ЯМогуПожаритьКартошку", но никак не "МеняМожноЖаритьКакКартошку"

Медитирую...
Ухожу из дискуссии, пока медитация не даст результатов (пока не особо)

[Psycho Tiger]

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

Напиши свою замену Sprite`а, не используя его в наследовании и композиции. Не получится.

[Wolsh]

"Интерфейс определяет поведение" тоже не понимаю.

Хорошо, другими словами – интерфейс описывает методы экземпляра. Это понятно? Он никак не описывает, что по отношению к экземпляру можно сделать, например, addChild(). Мало того, сам класс ДО этого тоже не описывает. Это подразумевается на уровне контейнера, который в метод addChild принимает только ДО. И всё. Если бы addChild принимал интерфейс, о чем вы так мечтаете, то всеравно вы никак не смогли бы описать этот факт в интерфейсе, только в сигнатуре метода addChild() класса DOC – совершенно в другом месте. Интерфейс не описывает методы других объектов по отношению к данному. Вы выворачиваете порядок наизнанку, отсюда и вывернутые методы-"решения" addAsChildTo(DOC).

[expl]

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

addAsChildTo(DOC).

А про это не надо замечания делать - я ради прикола этот код привел (который про то, как компонент добавляет сам себя в контейнере).

Напиши свою замену Sprite`а, не используя его в наследовании и композиции. Не получится.

Причем здесь композиция?
Мы, вроде, говорили о том, что если над объектом надо что-то сделать - то надо передавать объекты с типом базового класса,
а не с типом интерфейса, об этом же речь была?

Если ограничиваться передачей только экземпляров класса, то нельзя передать экземпляры, унаследованные другими путями.



Интерфейс описывает методы, интерфейс описывает методы, ... медитация идет нормально...

2 Wolsh:
"Говори, не спрашивай" - это тоже самое что "Интерфейс говорит "ЯМогуПожаритьКартошку", но никак не "МеняМожноЖаритьКакКартошку" ", или последний принцип взят на вооружение откуда-то еще?

[Котяра]

Интерфейс говорит "ЯМогуПожаритьКартошку", но никак не "МеняМожноЖаритьКакКартошку"

Не согласен. Повсеместо использую IExecutable для комманд

addCommand(command:IExecutable );

ну и для другого тоже.

addPoint(ICoordinates)

show(IModule)

ну и IBitmapdrawable - как раз "меня можно отрисовать в битмапу".