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