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

[Wolsh]

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

Я так долго распространялся про маркеры, что уже не хочу повторяться. IBitmapdrawable как маркер гарантирует только слепое согласие компилятора. Он никак не может проверить, действительно ли экземпляр IBitmapDrawable можно отрисовать. Это контракт между кодом и программистом. Точно также вы можете написать пустой интерфейс IAsChildAddable, принимать его и смело кастовать в ДО (так же по смыслу как отдается IBitmapDrawable методу draw(), ибо САМ компилятор так и не знает, действительно ли там есть что рисовать, или это наследник Event с приписанной ему имплементацией интерфейса).

addCommand(command:IExecutable );

Замечательно, и я, и все поступают так же, для этого и созданы интерфейсы, верно? Ведь Ваш IExecutable описывает метод execute(), вызываемый у экземпляра, а не над ним. Он не описывает метод addCommand(command:IExecutable), который можно применить к нему, а не вызвать у него. Так же, как и addChild.

[Psycho Tiger]

Wolsh дело толкает.
Я с ним.

[expl]

Забудем про нативное API

public interface IInventory
{
    function addItem(item:Item):void
    function removeItem(item:Item):void;
    function get items():Array;
}
...
public function onAddItemButtonPress(event:Event)
{
    var item:Item = new Item();
    inventory.add(item);
}

Вот мы щас над инвентарем проводим действия, или говорим инвентарю добавить элемент?
Где эта тонкая грань между "вызовом у" и "действием над"?

А так?

public function upgradeItem(item:Item)
{
   item.damage += 10;
   item.defence += 5;
}

Мы "над", теперь уже итемом, издеваемся, или "у" итема что-то вызываем?

[Wolsh]

Я уже потерял нить Вашего непонимания, поэтому просто отвечу как бы не чувствуя подвоха:
1. Здесь над экземпляром item производится действие addItem(item:Item). В то же время у экземпляра IInventory вызывается метод addItem(item:Item).
2. Здесь у экземпляра Item вызываются сеттеры set damage() и set defence(). Ну или меняются публичные свойства, я не в курсе.
Перечитав несколько страниц раньше, заметил таки нить. Вы слишком буквально поняли мои слова о том что требуется передавать Класс, если действие "над". Естественно, все зависит от вашей реализации, но кончится процесс тем, что Вы будете вызывать нативные методы у intrinsic-классов вроде ДОК. Тема была про addChild. В какие бы обертки, принимающие интерфейсы, вы его ни заворачивали, в конце махинаций будет написано DOC#addChild() и принимать он будет DO, хоть из кожи лезь. Мои слова не значили, что в любой метод надо передавать классы. Это зависит от того, что с аргументами будет происходить в методе. Если у аргумента-экземпляра будут вызываться методы, то предпочтительней интерфейс. Если же над этим экземпляром будут производиться действия, ни Класс, ни Интерфейс в этом процессе вообще не играют никакой роли. Важно только то, какого типа аргумент нужен этим действиям. Если это draw в битмапдату, то и карты в руки, передавайте интерфейс. Так вот у автора этим действиям (addChild) нужен Класс ДО. Необходим. Почему передается нечто, что заведомо не "является" (с точки зрения компилятора) ДО, мне абсолютно непонятно. Правильно построенное наследование решило бы эту проблему одним махом.
Если не получается наследовать компоненты от одного класса, то есть альтернатива наследованию – композиция. Не интерфейс! Интерфейс вовсе не заменяет наследование, это вещи параллельные.
Задача интерфейса максимизировать инкапсуляцию, "сократив" тип данных до одного-двух методов и сделав все остальные методы и вообще все переменные экземпляра полностью недоступными.
Интерфейс никогда ничего не "расширяет", он не способен ничего добавить экземпляру. Интерфейс "сокращает" экземпляр до необходимого в данной ситуации минимума. Это не матрешка, в которой лежит еще что-то и еще что-то. Это.. левый глаз последней, неоткрываемой, матрешки. Интерфейс говорит только о том, что У всех его экземпляров независимо от класса ЕСТЬ такой-то метод. Если Вам нужно вызвать этот метод, то вот он здесь Интерфейс. Но если Вы хотите добавить экземпляр в дисплейлист, то извините. Метод добавления работает только с типом ДО, реализованным в самом плеере. Никакие способности компонента его не интересуют.

[expl]

Да и не было подвоха.

Насколько понял, если не брать это пример с get displayObject() в интерфейсе, я пишу код точто таким же макаром как и ты, только описываю другими словами.

а get displayObject() тебе претит использовать из-за нарушения инкапсуляции (по-моему несущественного).

Напоследок, как бы выглядело API, если бы был интерфейс IDisplayObject:
- DisplayObject реализует IDisplayObject
- DisplayObjectContainer принимает объекты IDisplayObject
- Реализовывать IDisplayObject может только наследник DisplayObject (иначе исключение или ошибка компилятора - не важно)
На первый взгляд смысл интерфейса теряется, но это не так, даже с этим ограничением гибкость увеличивается.
Например мы можем сказать, что менеджер принимает интерфейс IManageredDisplayObject extends IDisplayObject
Тогда мы можем реализовать через разные наследники DisplayObject, где-то удобнее это сделать, отнаследовавшись от TextField, а где-то - от Shape.
Ну и да, можно добавлять на сцену IManageredDisplayObject без приведения типов.

[alatar]

Если бы да кабы, что ж тогда никто не голосует на джире?
http://bugs.adobe.com/jira/browse/FP-5164 (нужна регистрация)

[expl]

к тому моменту как они внедрят - технология сдохнет, да и шаблоны с типизированными функциями в 100 раз нужее.

[alatar]

Ну да, лучше ничего не делать.

[Psycho Tiger]

И это всё потому что написать as DisplayObject не круто? Атас.

[alatar]

Как раз это меня не волнует. Просто изредка доставляется мелкие неудобства. Причем даже самим адобовцам, вон во флексе IFlexDisplayObject накатали.