Ваш пример с DisplayObject слишком сложен, потому что он связан с некоторыми нерегулярными вещами в AS3. DisplayObject - это абстрактный класс, который вы не можете расширить в коде AS3, ближайший, который вы можете получить, это Sprite.
Что касается расширения и, в частности, расширения экранных объектов, мне неприятно звучать как укол, но я все равно спросил бы вас: действительно ли вы этого хотите? На этом пути много неприятностей. Унаследовав от класса, который имеет более 100 методов, вы создаете класс, который потенциально слишком раздут, с поведением, которое вы вряд ли будете полностью контролировать или даже понимать. Это обычная вещь для AS3 (исторически), она дорого обойдется вам с точки зрения разработки и обслуживания. Попробуйте использовать композицию, как было отмечено ранее, или служебные методы, которые специализируются на некоторых аспектах или различиях между вашей версией MovieClip и встроенной.
Однако, в целом, может существовать еще один подход, который очень похож на композицию, но не совсем тот же. Вы можете думать об этом как о «декораторе», но это не совсем то же самое. Идея состоит в том, что у вас есть класс, который не содержит реализации методов, вместо этого он ожидает, что реализации будут предоставлены во время выполнения. Рассмотрим пример ниже:
public class ClassWithDecorator
{
public function ClassWithDecorator(decorator:Vector.<Function>)
{
super();
this._decorator = decorator;
}
public function classMethod(integer:int, string:String):Boolean
{
return this._decorator[0].apply(this, [integer, string]);
}
}
Это позволит вам учитывать разные виды похожих объектов, предоставляя разные наборы методов для каждого класса. Это несколько менее строго с точки зрения типизации - поскольку вы «теряете» тип сигнатуры функции - вы, однако, будете уведомлены во время выполнения, если типы не совпадают. Ну, это компромисс.
Еще один недостаток - вы не сможете «проникнуть» в экземпляры этого класса на месте, где требуются некоторые предопределенные типы, даже если вы реализуете необходимые методы. Тем не менее, в некоторых случаях это жизнеспособные решения, если число различных типов объектов, возможно, слишком велико или не может быть предсказано во время написания кода.