Instantiate
オブジェクト指向のプログラムでは、わしらプログラマはクラスを書くが、実際の動作は基本的にインスタンスが担う。XCとかで、そのインスタンス化(instantiate)の処理で考えられる方針は、
- すべてプログラマがコードで instantiation を適宜記述する。それはプログラムの動作に関わる部分であり、プログラマのミッションだ。
- 動的言語かつ実行時コンパイル特性*1を利用し、規約に基づいて instantiation する。動作は 1 と変わらないが、プログラマの負荷が軽減される。
- 開発ツール（もしくは手書きの設定ファイル）を利用し、アプリケーションフレームワーク起動時に instantiation する。
もっとも基礎的なのは 1. で、応用として 2. がある。
2. は Web アプリ系特有（？）の手段*2なんじゃけど、これは非常に便利。
ビジュアル開発ツールの環境では 3. をせんといけん。オブジェクトをドロップした時点で、その instantiation をランタイムが保証せんと意味ないけえね。これは .NET や Interface Builder 、RPGツクールのような国産ゲームエディタから海外のゲームエンジンまで、ジャンルを問わず広く実装されとる。
ゲームエディタがまさにそれなんじゃけど、オブジェクトをドロップするという構築形態をとったとき、コードに触らせずに目的のものに近づけるには、エディタ上でそのままインスタンスのプロパティを弄ったり、デリゲートやスクリプトアタッチを変更できる必要がある。じゃけん、今日日のツールは必然的に、クラス定義やコンポーネントだけじゃのうて、インスタンスまで扱う範囲を広げんにゃいけん。
そんかしプロパティの変更や連携するインスタンスの変更で動作に幅のある汎用クラスは、こういったツールで適用が容易になり、カスタムコード量を抑えることができる。コードだけで書いとると、汎用クラスは結構見通し悪くて使いにくいんで、案外使われんところがあるけど。
じゃけど、そういうランタイムを作っても、肝心のエディタやツールの提供が遅れると、ただの設定ファイル手書きウザウザ開発環境ってことになって、嫌われる。
