Корректный оверрайд

[wvxvw]

Касательно addChild и им подобным - я все таки за то, чтобы этого не делать. Вернее, не совсем так, если делать, то в финальных классах, либо классах заточеных под какую-то определенную задачу, у которых будет ограниченный набор наследников, и все они будут опять же финальными. Даже более того, в виду того, что практика нашего мира такова, что получить хорошо, да что там хорошо, хоть как-то спроектированную схему классов к проекту - такого просто никогда не произойдет, я строю наследование по следующему принципу: пишется класс А и класс Б, сравниваются, если у них есть что-то общее, то пишется класс В, в куда это общее выносится, А и Б наследуются от В. Так я хоть немного застрахован от ситуаций, когда "внезапно" нужно переделывать базовый функционал, который я описал не там, где нужно.
Да, еще такой вариант, иногда нужно "немного" переделать базовый метод, если он делает что-то определенно не то. Например, тот же addChild может "своровать" ребенка у другого контейнера - переопределить addChild, чтобы он этого не делал - это как бы даже благородный поступок, по своему А переопределить его и бросить в нем ошибку, как это делает флексовый фреймворк - это "ой беда беда огорчение..."
Но, опять же, в том что касается дисплей объектов - я стараюсь их не трогать. B смысле, просто использовать их как контейнеры для графики, а если мне нужно описать логику - делаю это в классах, метдоы которых принимают эти самые визуальные объекты в качестве аргументов - так проще жить. Особенно в ситуациях когда например, хочется вернуть обратно метод супер-супер класса, и начинаешь ломать голову, как же его так перестроить. Вообще, очень часто получается, что функции, которые не привязаны к контексту (this) класса легче заменяются при необходимости.
Что я имею в виду:

public class SuperSuper extends Sprite
{
	protected static function doSomething(to:Sprite):void
	{
		to.x = 100;
	}
 
	public function SuperSuper()
	{
		super();
		doSomething(this);
	}
}

public class Super extends SuperSuper
{
	protected static function doSomething(to:Sprite):void
	{
		to.x = -100;
	}
 
	public function Super()
	{
		super();
		doSomething(this);
	}
}

public class Orphan extends Super
{
	protected static function doSomething(to:Sprite):void
	{
		to.y = 50;
	}
 
	public function Orphan()
	{
		super();
		// Заметте, что при традиционном подходе к наследованию 
		// это бы выглядело как-то типа super.super.doSomething();
		// что, вобщем не возможно.
		SuperSuper.doSomething(this);
		doSomething(this);
	}
}

Но с другой стороны у такого подхода есть недостатки - с точки зрения AS3 это вообще не наследование, а просто случайное совпадение имен. Такая практика не распростанена и скорее запутает читающего. Кроме того, нам нужно вызывать все функции с одним "лишним" аргументом (опять же именно изза того, что AS3 не считает такой подход наследованием). Очень часто this используется для хранения состояния объекта, например button.enabled и нам удобнее найти свойство напечатав точку после имени объекта, чем сравните:

static function clickHandler(event:MouseEvent):void
{
	// Предположим, что у класса Button существует методы:
	// static enabled(Button):Boolean
	// static enable(Button):void
	// get enabled():Boolean
	// set enabled(Boolean):void
	var button:Button = event.currentTarget as Button;
	if (enabled(button))
	{
		enable(button);
	}
	// Т.как редактор кода не знает, что enable() связан с SimpleButton - вы будете его долго искать
	if (button.enabled)
	{
		button.enabled = false;
	}
	// Потенциально прийдется писать лишний (возможно ошибочный) код, 
	// если вы задумаете переопределить button.enabled
}