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

[in4core]

Такой вот вопрос интересный возник.
Допустим :

class Component extends Sprite implements IComponent
//
var a:IComponent = new Component();
addChild(a) // exeption

Есть вариант решения :

in Component class :
 
function get instance():Sprite { return this };
//
addChild(a.instance)

Но это как то выглядеть неприятно.
Реально ли вообще обяснить компилятору что это DO без явново указания на это?
P.s

addChild(a as Sprite)

- еще хуже чем get instance

[zuxul]

такой подойдет?

var b:Component = new Component();
var a:IComponent = b;
addChild(b);

[expl]

addChild(a) // exeption

не exeption, а ошибка времени компиляции

Т.к. интерфеса IDisplayObject нет, то без приведения типов никак.
а избавиться от приведения типов с помощью такого трюка:

public interface IRenderer
{
    function get displayObject():DisplayObject;
    function get data():Object;
    function set data(value:Object):void;
}

- это вполне кошерно, ИМХО.
Даже появляется некоторая гибкость (не сильно нужная, правда), например, можно реализовать интерфейс классом, не являющимся наследником DisplayObject.

Проблем, чуток больше, конечно, чем если бы был интерфейс IDisplayObject, но, все же менее проблематично чем разбрасывать приведения типов по коду.

Пример:
Была проблема с использованием 2-х GUI-фреймворков. Были менеджеры переключения кнопок, классы пролистывания списков, в которых исползовались кнопки. Только вот кнопки в 2-х фреймворках наследовались от разных классов и подставить их обоих в эти менеджеры не получалось.
Как выход - это сделать интерфейс, и отнаследоваться от обоих фреймворков с реализацией этого интерфейса, а добавление сделать через метод get displayObject().

такой подойдет?

var b:Component = new Component();
var a:IComponent = b;
addChild(b);

Если есть завязка на Component,
придется вместо интерфейса использовать одну из его реализаций(а именно Component) - другую передать не получится, т.е. смысл использования интерфейса теряется.

[in4core]

Даже бы если и скомпилировалось - это ужасно было бы.
expl честно говоря ни разу не понял трюка. Можешь показать реальную реализацию?

[expl]

Погоди, ты же сам его используешь:

// кусок кода из Component, который реализует интерфейс IComponent
public function get instance():Sprite { return this };
 
//Код где-то в каком-то классе, который обрабатывает IComponent
public functin doSomething(a:IComponent):void
{
    addChild(a.instance);
    ...
    // работа с другими методами IComponent
}

т.е., код интерфейса так ведь выглядит?

public interface IComponet
{
    function get instance():Sprite;
    ...
    //другие методы
}

[in4core]

Именно так все и выгялдет. Но не очень мне нравится такая запись все же ( я об этом написал в топике ). Тоесть красивше в таком случае не сделать?

[expl]

Я путей красивше не знаю (по мне и этот сойдет вполне).
Зато знаю извращённее :

public interface IComponent
{
    function addSelfTo(container:DisplayObjectContainer):void;
 
    function removeSelf():void;
}
 
// Код компонента:
public class Component extends Sprite implements IComponent
{
    ...
    public function addSelfTo(container:DisplayObjectContainer):void
    {
         container.addChild(this);
    }
    ...
}
 
 
//Код где-то в каком-то классе, который обрабатывает IComponent
public functin doSomething(a:IComponent):void
{
    a.addSelfTo(this);
    ...
    // работа с другими методами IComponent
}

[in4core]

Ну извращенных методов это понятно )) мы и сами знаем) Лан всем спасиб

[Wolsh]

ужас((

Т.к. интерфеса IDisplayObject нет, то без приведения типов никак.

А если бы был? addChild() то принимает DisplayObject.

(a as Sprite) - еще хуже чем get instance

Не понял, чем хуже? И почему спрайт, а не ДО?

Добавлено через 23 минуты
Первый принцип SOLID – SPR, принцип единой ответственности (обязанности). Если Вы построили метод таким образом, что он принимает у Вас один тип данных, а работает почему-то с другим – это проблемы не языка, а архитектуры. Метод должен делать одно изменение. Естественно, это в идеале. Но если Вы решили нарушить этот принцип, а потом для избавления от возникших проблем согласны еще и сломать инкапсуляцию и иерархию, передавая детям ссылки на родителей, то тут даже ни о чем хорошем речи нет, не то что об идеальном.

[expl]

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

ужас((
А если бы был? addChild() то принимает DisplayObject.

addChild() само собой при этом должен был бы принимать IDisplayObject, но это все фантазии, надо радоваться что adobe вобщем достаточно удачно API плеера спроектировала.

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

Не понял, чем хуже? И почему спрайт, а не ДО?

Ну не DO, видимо, потому что надо какие-то фишки Sprite использовать, или просто потому что пофиг.

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