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

Добрый день! У меня возник следующий вопрос:
есть 3 класса: Step1, Step2,Step3, которые наследуются от Sprite и при этом имплементят интерфейс, допусти IStep.
Создаю переменную step, тип данных у которой IStep.
Когда я пытаюсь добавить такой объект на экран - мне пишут ошибку
Я конечно же могу написать step as DisplayObject, но чувствую что это неправильный подход. Как лучше решить эту проблему?

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

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

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

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

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

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

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

Если бы был интерфейс IDisplayObject, то его бы addChild и принимал, не?

Вариант перейти от "IStep is-a DisplayObject" к "IStep has-a DisplayObject" рассматривали? Т.е. у вас будет
Оно гораздо гибче в использовании (UI теперь можно кучей разных способов производить, а можно просто return this делать), да и идеологически более правильно.

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

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

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

single responsibility

Правильно.

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

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

Вот тут обсуждали