2-2-3:「代理人モデル」とは?


・ JDK1.1 以前の JDK1.0では、現行とはまったく違うモデルが採用されていました。 イベントを表すクラスは java.awt.Event クラスのみでした。 旧来のモデルでは、イベントは Component(およびそのサブクラス)の オブジェクトのメソッドによって処理されました。 コンポーネントのオブジェクトは、 「システムからイベントを受け取るウィンドウ」の役割と 「イベントを処理する」役割の両方を備えています。 自分自身で処理しきれない場合は、「イベントの伝搬」によって 他のオブジェクトに処理をまかせることもできましたが、 その相手は自分の外側にあるウィンドウのオブジェクトに限られました。 (Eventクラスに依存したプログラムも 互換性の立場から動作は保証されていますが、既にほとんどのアプリケーション では利用されていません。)
これに対して現行のイベントモデルでは、 コンポーネントから「イベントを処理する」機能を分離することが図られています。 コンポーネントは任意のオブジェクトに対して イベントの伝搬関係を作ることができます。 つまり、コンポーネントはイベントを検出する機能に特化し、 イベント処理は別のクラスのオブジェクトにまかせるわけです。 (これが「代理人(delegation)モデル」と呼ばれる理由です。) 旧来のものに比べてはるかに柔軟な処理が可能になりました。
ただし、そのために新しい概念がいくつか導入されています。 新しいイベントモデル用のイベントのクラス群、 それと Listener と Adapter です。 イベントを処理するクラスは、 EventListener の拡張である MouseListener, ActionListener など のインターフェイスを実装します。 それぞれで宣言された専用のメソッドがイベントの処理の記述に用いられます。 この仕組みによって、コンポーネント以外のオブジェクトでも イベント処理を行うことが可能になります。 あるいは Listener のメソッドを既に実装済みの Adapter のクラスを 拡張しても実現できます。 実際、それぞれの Listener インターフェイスに対応して、 Adapter と呼ばれる クラスが存在します。Adapter のクラスは、Listener に用意された メソッドを実装しています(ただし定義の中身は空)。 Adapterクラスのサブクラスは、すべてイベント処理の能力を持つことになります。


イベント処理の概念図