通常、イベント処理には少なくとも3つのコードが関与します。ここでは、3つのコードをA(イベント・ソース)、B(イベント・リスナー)およびC(すべてがまとめられたコンテナまたはその他のコード)と呼びます。
ソース・コンポーネントではイベントが生成されます。このコンポーネントでは、他のコンポーネントがこのイベントの通知を受け取るために使用できるイベント登録メソッド(add<Event>Listener
とremove<Event>Listener
メソッド)を提供する必要があります。
イベント・リスナー・インタフェースを実装するコンポーネントで、リスナー追加コールを使用してAに登録されます。理論上、イベント・リスナー・インタフェースを実装するものであればどのようなコンポーネントでもかまいませんが、通常は、あるプログラムの特定のイベントを処理するために作成されるprivateの匿名クラスです。
コード内でAとBがインスタンス化され、add< Event>Listener
メソッドがコールされます。
具体的に、JDeveloperでは次のようになります。
JDeveloperのJavaビジュアル・エディタでは、アクション・アダプタ・クラスが自動的に生成され、Cが定義されているのと同じ.java
ファイルに置かれます。JDeveloperは、イベントを受け取ってルートを指定するアクション・アダプタを生成します。アクション・アダプタは、Cに実装されているターゲット・イベント処理メソッドにイベント処理を委任します。ユーザーは、このイベント処理メソッドで、イベントに応答するコードを記述します。一般に、ユーザーはアクション・アダプタでは何も行いません。
java.awt.Container
の子です。
JDeveloperでは、コンテナCでイベント・リスナー・インタフェースを直接実装して(アクション・アダプタではなく)C自体をイベント・リスナーとして登録するという方法はとりません。そのかわりに、ある特定のイベントが複数のコンポーネントによって作成される場合の混乱を回避するために、アクション・アダプタというアプローチを利用しています。このアプローチを使用しないと、イベント・ハンドラで、イベントを適切に処理するためにどのコンポーネントでイベントが生成されたかを判断する必要が生じます。アクション・アダプタのアプローチを採用した場合、各アダプタ、そしてその結果として各イベント処理メソッドが、1組のソース/リスナーのペアとして表されます。
Javaビジュアル・エディタを使用した場合、エンド・ユーザーがイベントを認識するのは、主としてコンポーネントが含まれるクラスで実装する必要があるイベント処理メソッドとしてです。たとえば、エンド・ユーザーがbutton1というボタンをFrame1というコンテナに置き、button1が押されたときに何かが起こるようにする場合、次の一連のアクションが必要です。
actionPerformed
の右側をクリックします(actionPerformed
は、ボタンが押されたときに生成されるイベントです)。
button1_actionPerformed()
と呼ばれ、メソッドの本体は最初は空です。
バックグラウンドで、JDeveloperはイベント・リスニングの他の側面を処理する追加コードもFrame1.java
ファイルに生成します。
ActionListener
インタフェースを実装するアクション・アダプタの匿名の内部クラスを生成します。
button1.addActionListener()
をコールすることにより、自分自身をbutton1イベントのリスナーとして登録します。
このコードはすべてソース・ビューに表示されますが、開発者の主たる業務は、イベント発生時にアクション・アダプタによってコールされるイベント処理メソッドを記述することです。
JDeveloperによりデフォルトで生成される特定のタイプの内部クラス・イベント・アダプタは、匿名アダプタと呼ばれます。このスタイルのアダプタは、別個の(名前付き)アダプタ・クラスを作成しません。その結果、コードは簡潔で洗練されたものになります。
「プロジェクト・プロパティ」ダイアログのコード・スタイル・ページから必要なオプションを選択することにより、JDeveloperでのアダプタ・クラスの生成方法を制御できます。詳細は、「標準アダプタ・クラスの使用」を参照してください。
たとえば次のコードは、アクションが実行されたイベント用に、匿名アダプタを使用して生成されたものです。
button1.addActionListener(new java.awt.event.ActionAdapter() {
public void actionPerformed(ActionEvent e) {
button1_actionPerformed(e);
}
});
void button1_actionPerformed(ActionEvent e) {
// your code to respond to event goes here
}
エンド・ユーザーには、button1から発生する可能性のあるイベントがすべてプロパティ・インスペクタのイベント・ページにリスト表示されます。コンポーネントの作成者は、コンポーネント・クラスを作成する際に、そのクラスで生成されるすべてのイベントがプロパティ・インスペクタに表示されるようにする責任があります。Beanを使用するためにエンド・ユーザーに必要なことは、イベント処理メソッドのコードを記述することのみです。
上級のユーザーであれば、別の方法でイベントを作成します。たとえば、コンポーネントsrcがイベント・ソースで、コンポーネントlstnrがイベント・リスナーであり、クラスinit
でsrcとlstnrがインスタンス化されている場合、src.addListener(b)
をコールするコードをクラスinit
に挿入します。
JDeveloperのデフォルトのメカニズムは、次のとおりです。
単純化されたこのモデルでは、ユーザーがコンポーネント・パレットから選択するコンポーネントはイベント・ソースであればよく、イベント・リスナーである必要はありません。
JDeveloperでは、内部クラスのかわりに、標準のクラス・イベント・アダプタも生成できます。
標準イベント・アダプタは、宣言されたスコープ内のすべての変数にアクセスできる匿名アダプタとは異なり、パブリックまたはパッケージ・レベルでしかアクセスできません。
たとえば次のコードは、アクションが実行されたイベント用に、標準クラスを使用して生成されたものです。
// Registers the adapter as a listener to button1.
button1.addActionListener(new Frame1_button1_actionAdapter(this));
...
// Adapter class definition.
class Frame1_button1_actionAdapter extends java.awt.event.ActionAdapter {
Frame 1 adaptee;
Frame1_button1_actionAdapter(Frame1 adaptee) {
this.adaptee = adaptee;
}
public void actionPerformed(ActionEvent e) {
adaptee.button1_actionPerformed(e);
}
}
void button1_actionPerformed(ActionEvent e) {
// code to respond to event goes here
}
このコードを、前述のコード・サンプルと比較してください。JDeveloperでは、匿名の内部クラスを使用してコードが生成されています。アダプタを使用する方法では、どちらもアクションが実行されたイベントを処理するコードが生成されますが、匿名アダプタを使用した方がより簡潔になります。
標準アダプタをプロジェクトのデフォルトにするには、次のようにします。
これで、JDeveloperではイベント用に(匿名の内部クラスではなく)標準アダプタが生成されます。
Beanを開発する場合、Beanで生成する必要があるすべてのイベントについて考慮する必要があります。
コンポーネントをイベントが起動できるようにするには、次のようにします。
該当する既存のイベント・セットをAWTまたはJFCから選択します。
または
新規イベント・セットを作成します。
fire<yourEventName>Event()
Copyright © 1997, 2007, Oracle. All rights reserved.