Унаследовать интерфейс от DisplayObject'a

[Universe]

Добрый день! У меня возник следующий вопрос:
есть 3 класса: Step1, Step2,Step3, которые наследуются от Sprite и при этом имплементят интерфейс, допусти IStep.
Создаю переменную step, тип данных у которой IStep.
Когда я пытаюсь добавить такой объект на экран - мне пишут ошибку
35 Error: Implicit coercion of a value of type armor5.Tutorial:ITutorialStep to an unrelated type flash.display:DisplayObject.
Я конечно же могу написать step as DisplayObject, но чувствую что это неправильный подход. Как лучше решить эту проблему?

[Dukobpa3]

Никак:)
Во флеше нету интерфейса дисплейобжектов.
Придумаешь грамотный велосипед - поделись. А так костыльных вариантов кучу видел, да и сам писал.
Один из них использовать не интерфейс IStep, а какой-то BaseStep extends DisplayObject. А потом от него наследоваться.

[Universe]

Да уж...интересно, почему так получилось? Это провтык разработчиков или они специально так сделали?

[Dukobpa3]

SlavaRa много тебе расскажет про это, если захочет. Холиворили уже с ним на эту тему.
Я считаю недоработкой разрабов. Он с пеной у рта доказывал что всё ок и так надо.
В чем-то он конечно прав, но думаю можно было что-то придумать.

[Akopalipsis]

Объясните мне пожалуйста, в чем такая принципиальная разница, между интерфейсом и "абстрактным наследником" ?

[Dukobpa3]

Akopalipsis
А если подумать и еще раз почитать вопрос в топике? :)

[caseyryan]

Это провтык разработчиков или они специально так сделали?
Никакой это не провтык разработчиков. Все правильно сделано. Если бы можно было в дисплей лист толкать все что угодно, хоть Sound, какой толк был бы вообще в типизации?
Ну и что толку, если бы был интерфейс IDisplayObject? Все равно метод addChild принимает DisplayObject

Если это дисплей объект, то вполне нормальный подход писать as DisplayObject

[Simplifier]

Ну и что толку, если бы был интерфейс IDisplayObject? Все равно метод addChild принимает DisplayObject
Если бы был интерфейс IDisplayObject, то его бы addChild и принимал, не?

[maxkar]

Как лучше решить эту проблему?
Вариант перейти от "IStep is-a DisplayObject" к "IStep has-a DisplayObject" рассматривали? Т.е. у вас будет

interface IStep {
//...
function DisplayObject getUI();
}

Оно гораздо гибче в использовании (UI теперь можно кучей разных способов производить, а можно просто return this делать), да и идеологически более правильно.

[caseyryan]

maxkar, неплохой вариант. Одна поправка к коду

interface IStep {
//...
function getUI():DisplayObject;
}

;)

[Dukobpa3]

Тогда уж:
function get gui():DisplayObject;
Но, в целом, очень хорошая практика отделять логику от вида. И ждать от дисплей обжекта больше чем просто "отрисоваться" - не всегда правильно. Так что, тоже склоняюсь к композиции.

[Universe]

на мой взгляд не очень удобный вариант т.к. придётся имплементить в каждый класс который будет расширяться от данного интерфейса по сути избыточный метод function get gui():DisplayObject; Также везде придётся менять способ обращения, а тогда какая разница с привидением к DisplayObject

[Dukobpa3]

single responsibility

[Babylon]

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

[Psycho Tiger]

Сильно зависит от реализации. В общем случае ради такого трюка создавать ещё одну сущность, которая будет просто возвращать другую – это костыль. Бритва Оккама для бритья щетины.

По теме – видимо, я больше солидарен с Славой. То есть, IDisplayObject никому не помешал бы, но от лишнего кастинга никто не умрёт. А вот если какой-нибудь чудик реализаует IDisplayObject в своём классе, например, наследуемый от NetStream – его в дисплай-лист уже не добавить, но вот компайл-тайм соглашения будут соблюдены. Тут вопрос между RTE vs Compile Time и решение адоуба, в принципе, очевидно.

[Wolsh]

Вот тут (http://flasher.ru/forum/showthread.php?t=157498&page=7) обсуждали