JAVAイベント処理メカニズムをゼロから理解する

「JAVA イベント処理メカニズムをゼロから理解する (1)」の最初のセクションの例は単純すぎて、誰もがそのようなコードはまったく役に立たないと感じるほど単純です。しかし仕方がありません。この役に立たないコードを書き続けて、次の段階の本当に役立つコードにつなげる必要があります。

1: イベント駆動モデルの概要

イベント駆動モデルはオブザーバー パターンのアップグレードされたバージョンであると言いたいので、対応する関係について話さなければなりません:

オブザーバーリスナー(生徒)に対応します

オブザーバーはイベントソース(教師)に対応します

イベントソースはイベントを生成し、イベントはイベントソースを持ち、リスナーはイベントをリッスンします。物事について話すのが好きな友人は、イベントの生成やイベントの監視とは何なのか、イベントとは一体何なのか、と言うかもしれません。

パニックにならないでください。コードで言えば、イベントはクラスであり、イベント ソースもクラスです。これには、イベント ソース (つまり、教師、つまり、オブザーバー)、イベント (クラス、以下を参照、通常は Event または EventObject で終わります)、リスナー インターフェイス、特定のリスナー (つまり、生徒、つまり オブザーバー) の 4 つのカテゴリが関係します。

前回の記事の最初のセクションで述べたように、JDK にはもちろん既成のイベント モデル クラスがあり、それらを 1 つずつ確認してみるのもよいでしょう。

まずリスナーに注目してください (つまり、学生、つまりオブザーバーの皆さん、気にしないでください。注意するために括弧を削除し続けています。これは、皆さんにより深い印象を与えるためです)、

パッケージ java.util;

/ * *

* すべてのイベントリスナーインターフェイスが拡張する必要があるタグ付けインターフェイス。
* @JDK1.1 以降
*/
パブリック インターフェイス EventListener {
}

これは、宣言されたメソッドすら持っていないので、その存在の意味は何でしょうか?オブジェクト指向のアップキャストを思い出してください。その意味は、すべての呼び出し元に私がリスナーであることを伝えることです。

イベント、つまり Event または EventObject の最後にあるクラスを見てみましょう。このクラスには、イベント ソース (つまり、教師、オブザーバー) を返す getSource メソッドが含まれています。 ;

/**

*

* すべてのイベント状態オブジェクトの派生元となるルート クラス。

*

* すべてのイベントは、オブジェクト、つまり「ソース」への参照を使用して構築されます。
* これは論理的に問題のイベント
* が最初に発生したオブジェクトとみなされます。
*
* @since JDK1.1
*/

public class EventObject は java.io.Serializable を実装します {

private static Final longserialVersionUID = 5516075349620653480L;

/**

* イベントが最初に発生したオブジェクト。

    */

protected transient Object source;

/**
* プロトタイプのイベントを構築します。
*

* @param source イベントが最初に発生したオブジェクト。

* @例外 IllegalArgumentException ソースが null の場合。
     */
public EventObject(オブジェクトソース) * @return イベントが最初に発生したオブジェクト
getName() + "[source=" + source + "]";
}
}


このクラスも非常に単純です。オブザーバー パターンの上位クラスと結果にも多くのロジックとメソッドがある場合、イベント駆動モデルの上位クラスとインターフェイスは単に何も見ることができません。そうです、

イベント駆動モデルでは、JDK の設計者は最高レベルの抽象化を実行しました。これは、上位クラスに「私はイベントです (イベント ソースを含む)、または、私はリスナー！

2: 教師の宿題のイベント駆動型モデル バージョン


古いルール、最初にクラス図を示しましょう:

次に、コードでそれを実装します:

Observer インターフェース (学生)。イベント駆動型モデルでは、メソッドのないインターフェイスは EventListener のみであるため、最初に独自のインターフェイスを実装できます。前の記事のコードとの一貫性を保つために、このインターフェイスで宣言したメソッドの名前も update と呼ばれます。もちろん、ビジネス ニーズによっては、この名前を使用したり、他のメソッド宣言を追加したりすることはできないことに注意してください。

package com.zuikc.events;

import java.util.Observable;

public Interface 宿題Listener extends java.util.EventListener {

public void update(宿題EventObject o, Object arg);
}

Thenオブザーバー クラス (student) を次のように実装します。

package com.zuikc.events;

public class Student は、宿題リスナーを実装します{
private String name;
public Student(String name){
this.name = name;
}
@Override
public void update(宿題イベントオブジェクト o, オブジェクト arg) {
教師 Teacher = o.getTeacher();
System.out.printf("生徒 %s は、%s が宿題を割り当てたことを観察しました (実際に通知されました) }

}

前回の記事と比べて変化はありますか？

次に、次のようにイベント サブクラスを実装します。

package com.zuikc.events;

public class 宿題イベントオブジェクト extends java.util.EventObject {

public 宿題イベントオブジェクト(オブジェクト ソース) {
スーパー(ソース) ;
}
public 宿題EventObject(Teacher Teacher) {
use using using use using out out off out out out out of ’ s ’ ’ s ‐ ‐ ‐ ‐‐ ‐ to これは、getSource メソッドをカプセル化する getTeacher メソッドです。親クラス EventObject を取得し、イベント ソースを取得します。理論的には、親クラスの getSource メソッドを使用することも可能ですが、それをサブクラスに再カプセル化すると、より読みやすくなります。

次に、イベント ソースである Teacher クラスがあります。次のようになります。
private List宿題;
/*

* 教師クラスは独自のリスナー (生徒) のリストを維持する必要があります。なぜですか?

* オブザーバー パターンでは、教師は java.util.Observable から継承された被観察者であり、Observable にはこのリストが含まれています

* 現在はこのリストがないため、自分でリストを作成する必要があります

*/

private Set

public String getName() {

return this.name;

}

public Teacher(String name) this.name = name;

this.宿題 = new ArrayList();

This 。宿題リスナーリスト = new HashSet();

} }

public void set宿題(String宿題) {
System.out.printf("%s 割り当てられた宿題 %s n", this.name, 宿題);
宿題を追加します。 （宿題）;

}
public void addObserver(宿題リスナー宿題リスナー){
宿題リスナーリスト.add(宿題リスナー);
}

}

このクラスは少し長いですが、注目に値することがいくつかあります:

まず、先生Teacher には親クラスがありません。イベントのイベント ソース Source は 宿題イベントオブジェクトにカプセル化されます。これには何の問題もありません。ビジネス オブジェクトはフレームワーク コードから分離されており、分離は非常に適切です。ただし、このため、Teacher 内の生徒のリストを自分で管理する必要があるため、変数 homeListenerList を確認しました。

2 番目に、オブザーバー モードでは、Observable の NoticeObservers を直接呼び出して、監視対象に通知します。そのため、次のコードを確認しました。イベント、宿題);

}

全く問題ありません。引き続きクライアント コードを見てみましょう。 {

public static void main(String[] args) {

Student Student1= new Student("张三");

Student Student2 = new Student("李思");

Teacher Teacher1 = new Teacher ("ZUIKC") );

Teacher1.addobServer (Student2);

Teacher1.Set宿題 (「インシデント メカニズム」); クライアントの観点からは、まったく変更されていません。オブザーバー モードのクライアント コードと同じですが、内部実装メカニズムにはイベント メカニズムを使用します。

次に、オブザーバー パターンとイベント駆動モデルの違いをまとめてみましょう:

1: イベント ソースはパターンやモデル自体の親クラスを継承しなくなり、ビジネス コードが完全に切り離されます。イベント モデルでは、各リスナー (オブザーバー) が独自のインターフェイスを実装する必要があります。そうです、サブテーブルにはクリック、ダブルクリック、移動などのイベントがあり、それぞれコードの柔軟性が向上しています

とにかく、初心者向けのコードをたくさん使用して実装しました。イベント駆動型モデルについては、実用的ではありませんが、その原理についても説明します。次のセクションでは、少し複雑で一見便利そうなコードをいくつか見ていきます。

以上がJAVAイベント処理メカニズムをゼロから理解するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。