Quantumwave.com - Different ways of Inheritance in Flash

以下のドキュメントは、著者であるQuantumwave Interactive Inc.のDave Yang氏の許可を得て
"Different ways of Inheritance in Flash"を翻訳したものです。翻訳は上野直彦、北沢純(FACEs)の
二人によって行われました。オリジナルのドキュメントのURLは
http://www.quantumwave.com/flash/inheritance.htmlです。

Flash 5とFlash MXでの継承におけるいくつかの異った方法について

Flashで継承を設定する最良の方法はどれかということについていくらか混乱があるようだ。この記事ではそれらの違いについて説明を試み、混乱を払拭できればと思う。

この記事の最初のパートはFlash 5を扱っている。2番目のパートはFlash MXを扱っている。

マクロメディアのドキュメントでは、継承を確立するやり方は以下のようになる:

SubClass.prototype = new SuperClass();

この行で行われているのは、SubClassのprototypeオブジェクトをSuperClassの新規インスタンスに設定するということだ。 SuperClassのインスタンスにおける全てのプロパティとメソッドがSubClassのprototypeチェーンに割り当てられる - よってSubClassの全てのインスタンスがSuperClassインスタンスのプロパティとメソッドにアクセスすることができる。

ここでは、この構文の前に定義されたSubClass（コンストラクタ関数）に戻って見てみよう。functionが定義されたのがいつであれ（呼び出される前でも）いくつかのプロパティは自動的に与えられる。

それらのプロパティの一つがprototypeだ。

prototypeオブジェクトも自分自身のプロパティを持っている。ドキュメントに書かれているプロパティは: constructorと __proto__である。constructorプロパティはSubClass自体を参照しており、__proto__はSubClassのスーパークラスのprototypeオブジェクトを参照している。

混乱したかな？大丈夫 - 実際はとても単純だ。

SubClassが定義されたとき、そのSubClassのスーパークラスとは何か？デフォルトでは、全てのオブジェクトはスーパークラスとして Object（大文字'O'の）を継承している。よって SubClass.prototype.__proto__は Object.prototypeを参照している。

それでは、次の文が実行されたあと、SubClassのprototypeオブジェクトには何が起こるか？

SubClass.prototype = new SuperClass();

constructorと__proto__の両方が新しい値で上書きされる。それらの新しい値の内容は実装に依存する。例えば、Flash 5とJavaSctiptでは constructorはSuperClassを参照し、 __proto__はSuperClass.prototypeを参照する。しかし、 SubClassインスタンスのconstructor はSuperClassではなくSubClassであるべきだ。

	SubClass.prototype = new SuperClass();
	
	// 次の2行はFlash 5ではバグのため正しい結果を返さない。
	// constructorの比較は、代わりにNetscapeでやってみよう
	trace(SubClass.prototype.constructor == SubClass);           // false
	trace(SubClass.prototype.constructor == SuperClass);         // true
	
	trace(SubClass.prototype.__proto__ == Object.prototype);     // false
	trace(SubClass.prototype.__proto__ == SuperClass.prototype); // true

Flash 5における継承で'new'を使うにはいくつか問題がある:

constructor プロパティが正しくない（ SuperClassでなくSubClassを参照する）。

SuperClassのconstructorを実行して継承用のインスタンスを生成する。

これには3つの副作用がある:

a) スーパークラスの新規インスタンスを保存するために余計にメモリが使われる。

b) スーパークラス／サブクラス関係の考え方に反している：サブクラスがスーパークラスでなくスーパークラスのインスタンスを継承している。

c) スーパークラスのコンストラクタが必要もないのに実行される。staticプロパティが、スーパークラスのコンストラクタが何度実行されたかを追跡するために使われるとしたら、あるいはコンストラクタがムービークリップを付加してstatic変数を深度にしたがってインクリメントするとしたら、'new'宣言はそれを台無しにしてしまう。例えば:

	function SuperClass(x, y) {
	   // Static（クラス）プロパティ
	   SuperClass.invokeCount++;
	
	   this.x = x;
	   this.y = y;
	}
	
	SuperClass.invokeCount = 0;  // staticプロパティを初期化
	
	SuperClass.prototype.superMethod = function() {
	   trace("this.x"+ this.x +", this.y:"+ this.y);
	}
	
	//------------------------------------------------------------------------
	
	function SubClass(x, y, z) {
	   // SuperClassのプロパティを継承、初期化
	   this.tmpBase = SuperClass;
	   this.tmpBase(x, y);
	   delete this.tmpBase;
	
	   this.z = z;
	}
	
	trace(SubClass.prototype.__proto__ == Object.prototype);     // true
	
	SubClass.prototype = new SuperClass();
	
	trace(SubClass.prototype.__proto__ == Object.prototype);     // false
	trace(SubClass.prototype.__proto__ == SuperClass.prototype); // true
	
	SubClass.prototype.subMethod = function() {
	   trace("this.z"+ this.z);
	}
	
	//------------------------------------------------------------------------
	
	var o = new SubClass('X','Y','Z');

ここでは

o.constructor 
        == SuperClass

だが、これはSubClassになるべきだ。また、 SuperClass.invokeCountは1ではなく2だ。

Flash 5は、'new'を使うと、FOR..INループ使用中にプロパティの重複が起こるバグがある。for (var p in o) { trace(p +":"+ o[p]); }
出力:
-------
subMethod:
superMethod:
y:Y
x:X
z:Z
y:Y
x:X
誤って'new'宣言がそのクラスの prototype定義の後に置かれてしまったら、 prototype内の全てのものが消し去られる:
SubClass.prototype.subMethod = function() { trace("this.z"+ this.z); } SubClass.prototype = new SuperClass();subMethod() が無くなってしまう!

この問題を解決するためには、継承に別の方法を用いる:

この行を:

	SubClass.prototype = new SuperClass();

このように変える:

	SubClass.prototype.__proto__ = SuperClass.prototype;

この一行を変えるだけで全ての問題が解決される!

この行はSubClassの__proto__ プロパティをSuperClassのprototypeに設定することで、SubClassとSuperClassの間のリンクを設定する。SuperClassの prototypeチェーンにある全てのメソッド（もしあればプロパティも）がこれで SubClassのprototypeを通じてアクセスできるようになる。これがprototypeベースの継承の基本動作である。

Flash MXではどうだろう?

上のリストで挙げられた問題のいくつかはFlash MXで修正された:

SubClass インスタンスのconstructorプロパティがSubClassを正しく参照するようになっている。しかし、継承の設定に'new'構文が使われる場合は、SubClass.prototype.constructorはまだSuperClassを参照している。
FOR..INループにおけるプロパティ重複のバグは修正された。
constructorプロパティの参照が正しい結果を返す。

Flash MXで 'new'を使う場合に問題がいくつか残っている:

継承に'new'を使うとやはりconstructorが必要もないのに実行されるのでconstructorの中に置けるものが限られる（例：ムービークリップの付加、深度カウンタのインクリメント、_xと_yの座標がおかしくなる）。constructor内部にこの問題を回避するコードを書くことはできる。しかし、そうするとコードが理解しづらくなり実行時のオーバーヘッドが増える。スーパークラスのインスタンスを作るとFlash 5と同じくメモリが浪費される。
'new'を使用した後のSubClass.prototype.constructor が正しく SuperClassSuperClassを参照してくれない。
継承を確立するために__proto__を使うと、 super演算子がconstructor内で失敗する。以下に解決法を示す:
- constructor内でsuperを使うのではなく、スーパークラスのプロパティを継承する従来のFlash 5メソッドを使う:
```
this.tmpBase = SuperClass;
this.tmpBase(args);
delete this.tmpBase;
```
- extend()メソッドを使う（ 'extends'という's',の付いた単語は将来の使用のために予約されている）。これはドキュメント化されていない__constructor__プロパティを使用している。このメソッドはコンストラクタでのsuper()の使用をサポートしている。:
```
Function.prototype.extend = function(superClass) {
   this.prototype.__proto__ = superClass.prototype;
   this.prototype.__constructor__ = superClass;
   ASSetPropFlags(this.prototype, ["__constructor__"], 1);
};

ASSetPropFlags(Function.prototype, ["extend"], 1);

SuperClass = function(a) {
   this.a = a;
};

SubClass = function(a, b) {
   super(a);
   this.b = b;
};

SubClass.extend(SuperClass);
```

それではどのメソッドを使うべきか？

Flash 5では、上で述べた色々な問題から、__proto__を使うのがより間違いのない選択だ。

Flash MXでは、これは厳しい選択だ。「標準」に準拠する必要があるのか? あるいは、prototypeチェーンに直接連なっているクラス間の関係を定義することにより不必要なオーバーヘッドとメモリの浪費を避ける方がよいのか?

'new'を使う場合の隠された意外な部分に対処するには

constructorプロパティが既に使われているなら、 'new'を使ったそのすぐ後にこのように正しいconstructorに手動で設定し直すことができる:SubClass.prototype.constructor = SubClass;
継承を使う場合コンストラクタ内で何を避けるべきかを知っておく。あるいは、constructor内の初期化コードをバイパスするコードを追加する。
Branden Hallのprotolink(2003/9/2現在、リンク先は存在しない)による解決法を試してみる。

'new'を使う理由

上で示されたような問題があるにも関わらず、私は __proto__を使わない2つの理由を挙げることができる:

__proto__プロパティはECMA-262の仕様に含まれていない。

これはNetscape（JavaScript）では使えるがそれより新しいRhino（JavaでプログラムされたJavaScript実装。ColdFusion MXの.asr拡張子のついたサーバサイドActionScriptにも使われている）やSpiderMonkey（C++でプログラムされたJavaScript実装。Flash Communication Serverの.asc拡張子のついたサーバサイドActionScriptにも使われている）では使われていない。Internet Explorer（JScriptとJScript.Net）にもない。コードの移植性とECMA-262標準への準拠のため、 __proto__は避けるべきだ。
Macromediaのドキュメントや実例と、その最良の実践についてのホワイトペーパー (pdf)（PDF）はECMA-262標準を推奨している。

コーディングスタイルを標準化してコードが他の開発者にも容易に理解できるようにするのはいいことだ。一つの例として、以下のように継承メソッドをカプセル化するやり方がある:

SubClass.extend(SuperClass); // 上記の extend()メソッドを使う

__proto__を使う理由があるか？

__proto__プロパティはFlash MXで推奨されないわけではない。実は、ActionScript辞書 とFlashヘルプのマニュアル両方でドキュメント化されている。これはprototypeチェーンに沿った、クラス=オブジェクト間の最も直接的なリンクであり、当分は後方互換性のためにFlashに残っているだろう。

もう一つの理由は、継承だけのためにスーパークラスのインスタンスを保存してメモリを無駄にしたくないということだ。prototypeチェーンを形成するためにスーパークラスとサブクラスの間の関連を直接定義しよう！これが特に重要なのは、もっと複雑なクラスを用いた大きなプロジェクトかもしくはメモリの制限された小さなデバイスの場合だ。

ActionScriptはprototypeベースの言語なので、__proto__の仕様を避けるのは筋が通らない。なぜならprototypeと__proto__はprototypeチェーンを形成するために互いに依存しているからだ。このプロパティの使用が想定されていないなら、JScriptやECMAScriptのように隠蔽するか読みだし専用にしておくべきだ。

ところで、なぜconstructor プロパティが読みだし専用でないのか考えたことがあるだろうか？

ここからどこに進むか？

上で示したような問題を克服するには、クラスベースの言語が助けになるだろう。最も近い実例は、Microsoft's JScript .Netだ。これはECMA-262 edition 4 proposalに準拠している。今実際に使えるものであり、prototypeとクラスベースのオブジェクトの両方、継承も使える。edition 4(第四版)に基づいたJavaScript（ECMAScript）の未来は約束されている。

ActionScriptがこのような方向に進みクラスベースのオブジェクトと継承を実装するべきだと思うなら、 wish-flash@macromedia.comに意志表示をしてほしい。

こちらも参照: Object 継承, 仮想MovieClip クラス, staticなプロパティとメソッド

Flashのβプログラム中これらの問題を探索、提起してくれたBranden Hall, Colin Moock and Robert Penner に感謝（アルファベット順）。これらの問題は以下の3つの本全てで読むことができる: OOP with ActionScript, ActionScript for Flash MX: The Definitive Guide, and Robert Penner's Programming Macromedia Flash MX。これらの本はかなりお勧めだが、私がOOP本とRobertの本の両方でテクニカルエディタでありColinの本でβ読者だったからというわけではなく、これらの本がハードコアなActionScriptプログラマにとって有益な情報であるという点で際立っているからだ。

ソースをダウンロード: mxInheritance.zip (Flash MX フォーマット)

Flash 5(前の版)用デモ: setInheritance.zip & setInheritance.sit

Last updated on: Nov 10, 2002 - Copyright �.A�N) 2002 Dave Yang / Quantumwave Interactive Inc.

元記事のURLはhttp://www.quantumwave.com/flash/inheritance.htmlです。
日本語訳はQuantumwave Interactive Inc.のDave Yang氏の許可を得てFACEs Projectが行いました。

HOME