lablab.jp （日本語版）

デリゲートは、本質的にコールバック・メカニズムです。デリゲートによって、コールバック・プログラミングの全ての長所を利用することができます。交換可能性においては、クラス継承もデリゲートと同様に役に立ちます。したがって、クラス継承とデリゲートを区別して使い分けることが、重要になってくると思われます。そのために、クラス継承とデリゲートの特性の違いを理解する必要があるでしょう。

以下のクラスを見てください。

1. PMMonitor と呼ばれているこのクラスは、１週間読まれていないプライベートメッセージを持つユーザーをリストアップして、彼らにメールを送ります。
2. このクラスを使用するコードは、ブロックに含まれています。
3. その機能は、ブロックをサイトに置くことによって動作中になります。

言い換えると、プログラム・カウンタは、このクラスのコードを通過（実行）します。

さて、あなたは、このクラスが管理者に CC を送ることができるならば、それが自分にとってより便利になると考えました。そして、あなたはサブクラスを定義して、CC を送るために基底クラスをオーバーライドしました。



しかし、それは動作しません。他のコードが、あなたが新作したサブクラスの名前を知らないため、そのサブクラスは、どこからも呼ばれません。言い換えると、プログラムカウンタは決してこのサブクラスを通過しません。あなたがサブクラスのインスタンスを作成するコードで、基底クラスのインスタンスを作る元のコードを取り替えるまで、あなたのサブクラスは機能しないでしょう。

クラス継承は、プログラム上で開発者に機能を交換する可能性をもたらします。しかし、それはソースコードの変更を必要とします。 PMMonitor がデリゲートを持っていれば、機能を交換するか、機能を加えるためにそれを活用することができます。この場合、サブクラスを定義して他の箇所のソースコードを変更する必要はありません。

デリゲートを持つクラスが「PMMonitorDash」であると仮定しましょう。PMMonitorDash は、固定機能の代わりにデリゲートを使います。したがって、 PMMonitorDash のデリゲートにあなたの関数を登録すれば、あなたのコードが PMMonitorDash で働くことになります。



XOOPS Cube ではカスタマイズするために基本クラス群を取り替えることができます。それは、最も抜本的な改造方法ですが、しかし、ハードワークでもあります。ユーザーは、それを最後の手段と呼ぶかもしれません。その点、デリゲートは XOOPS Cube で最も簡単な改造方法になるでしょう。