デリゲート

　さっきの話は、デリゲートの存在意義とも関係がある。サブクラスを作ってカスタムコードを記述するやり方は、 Instantiation シーケンスを変更できんことにはオンステージさせられん。ほとんどの言語ではインスタンスのクラスを hot swap することはできんので、元のクラスをインスタンス化するんじゃのうて、カスタムサブクラスのほうをインスタンス化するように色んな箇所を変更せにゃあいけん。ビジュアル開発ツールの場合、最悪オブジェクトの削除・再ドロップが必要になる。

　一方で、デリゲート設定の場合は生成済インスタンスへのオペレートじゃけん、インスタンスの生成に関わる部分を変更する必要がないというメリットがある。ゲームエディタとかだと配置済のオブジェクトにアタッチするスクリプトを変更するだけじゃけど、まさにそれがデリゲートの話になる。

　まぁ結局両方サポートせんといけんのじゃけどね。 Interface Builder なんかは削除・再ドロップをせんでもええように、インスタンス化を行ったままクラスを変更できるようになっとる。

　あと先ほどの投稿の 2. にあたる「規約に基づいとけば勝手にインスタンス化が行われる」場合は、それがあらゆる状況でそうなら、サブクラスを定義したときに Instantiation を変更する必要がない。 Web フレームワークでデリゲート的なアプローチの必然性が低いのはこのためじゃと思う。ほとんどのフレームワークは規約に基づいてファイルとサブクラスを定義しておくと自動的に読み取ってインスタンス化するシーケンスが入っとる。じゃけん、カスタムサブクラス中心の開発をガンガンやってけるわけです。非常にうまい仕組みじゃと思う。

　XCはカスタム性のユーザーレベルでのアタッチのためにデリゲートを採用したが、 0.9 のリリース後、 Instantiation は弄りとうないという人が一定数おることが分かってきた。今のデリゲートの負荷で、 Cocoa とかと同じスタイルの用途には耐えれんけー、1.0でデリゲートを強化して、開発でももっと使えるようにする必要がある。

　カスタムサブクラスとデリゲートは、どちらも低レベルでは間接ジャンプのジャンプ先を変更しとるだけにすぎんけえ、人間側の作業過程のほうが違いが大きい。