読者です 読者をやめる 読者になる 読者になる

Instantiate

XC

 オブジェクト指向のプログラムでは、わしらプログラマはクラスを書くが、実際の動作は基本的にインスタンスが担う。XCとかで、そのインスタンス化(instantiate)の処理で考えられる方針は、

  1. すべてプログラマがコードで instantiation を適宜記述する。それはプログラムの動作に関わる部分であり、プログラマのミッションだ。
  2. 動的言語かつ実行時コンパイル特性*1を利用し、規約に基づいて instantiation する。動作は 1 と変わらないが、プログラマの負荷が軽減される。
  3. 開発ツール(もしくは手書きの設定ファイル)を利用し、アプリケーションフレームワーク起動時に instantiation する。


 もっとも基礎的なのは 1. で、応用として 2. がある。
  2. は Web アプリ系特有(?)の手段*2なんじゃけど、これは非常に便利。

 ビジュアル開発ツールの環境では 3. をせんといけん。オブジェクトをドロップした時点で、その instantiation をランタイムが保証せんと意味ないけえね。これは .NET や Interface Builder 、RPGツクールのような国産ゲームエディタから海外のゲームエンジンまで、ジャンルを問わず広く実装されとる。

 ゲームエディタがまさにそれなんじゃけど、オブジェクトをドロップするという構築形態をとったとき、コードに触らせずに目的のものに近づけるには、エディタ上でそのままインスタンスのプロパティを弄ったり、デリゲートやスクリプトアタッチを変更できる必要がある。じゃけん、今日日のツールは必然的に、クラス定義やコンポーネントだけじゃのうて、インスタンスまで扱う範囲を広げんにゃいけん。

 そんかしプロパティの変更や連携するインスタンスの変更で動作に幅のある汎用クラスは、こういったツールで適用が容易になり、カスタムコード量を抑えることができる。コードだけで書いとると、汎用クラスは結構見通し悪くて使いにくいんで、案外使われんところがあるけど。

 じゃけど、そういうランタイムを作っても、肝心のエディタやツールの提供が遅れると、ただの設定ファイル手書きウザウザ開発環境ってことになって、嫌われる。

*1:シンボルテーブルへランタイム時にアクセス可能

*2:規約は文字列に基づいたクラスや関数の定義の有無で動作を切り分けるんがほとんどじゃけん、スクリプト言語といっても strip 後のバイトコードにはこの手段は適用できん。じゃけどサーバーアプリに該当する Web アプリではシンボルを吹っ飛ばす必要がないどころか、実行時コンパイルで動かすケースがほぼ全てなんで、ガンガン使っていける。Web特有と書いたけど、スクリプトプログラミングの一般的なテクニックかも