從零開始理解JAVA事件處理機制（2）
第一節中的示例過於簡單《從零開始理解JAVA事件處理機制（1）》，簡單到讓大家覺得這樣的代碼簡直毫無用處。但是沒辦法，我們要繼續寫這毫無用處的代碼，然後引出下一階段真正有益的代碼。
一：事件驅動模型初窺
我們要說事件驅動模型是觀察者模式的升級版本，那我們就要說說其中的對應關系：
觀察者對應監聽器（學生）
被觀察者對應事件源（教師）
事件源產生事件，監聽器監聽事件。愛鉆牛角尖的朋友可能會說，我擦，什麽叫產生事件，監聽事件，事件事件到底什麽？
莫慌，如果我們用代碼來說事，事件源它就是個類，事件就是事件源中的那幾行業務代碼。這裏面一共牽扯到四個類，事件源（即教師、即被觀察者）、事件、監聽器接口、具體的監聽器（即學生、即觀察者）。
就像我們上一篇文章中的第一節提到的一樣，JDK中當然有現成的事件模型類，我們不妨來一個一個的查看一下吧。
首先看監聽器（即學生、即觀察者，大家不要嫌我煩，不停滴括號提醒，這是為了不停滴給大家加深印象），
package java.util;
/**
* A tagging interface that all event listener interfaces must extend.
* @since JDK1.1
*/
public interface EventListener {
}
簡單到不能再簡單了，對吧，甚至連一個聲明的方法都沒有，那它存在的意義在哪？還記得面向對象中的上溯造型嗎，所以它的意義就在於告訴所有的調用者，我是一個監聽器。
再來看看事件源（即教師、即被觀察者），
package java.util;
/**
* <p>
* The root class from which all event state objects shall be derived.
* <p>
* All Events are constructed with a reference to the object, the "source",
* that is logically deemed to be the object upon which the Event in question
* initially occurred upon.*
* @since JDK1.1
*/public class EventObject implements java.io.Serializable {
private static final long serialVersionUID = 5516075349620653480L;
/**
* The object on which the Event initially occurred.
*/
protected transient Object source;/**
* Constructs a prototypical Event.
*
* @param source The object on which the Event initially occurred.
* @exception IllegalArgumentException if source is null.
*/
public EventObject(Object source) {
if (source == null)
throw new IllegalArgumentException("null source");this.source = source;
}/**
* The object on which the Event initially occurred.
*
* @return The object on which the Event initially occurred.
*/
public Object getSource() {
return source;
}/**
* Returns a String representation of this EventObject.
*
* @return A a String representation of this EventObject.
*/
public String toString() {
return getClass().getName() + "[source=" + source + "]";
}
}
這個類也很簡單，如果說觀察者模式中的上層類和結果還帶了不少邏輯不少方法的話，那麽事件驅動模型中的上層類和接口簡直看不到任何東西。沒錯，
事件驅動模型中，JDK的設計者們進行了最高級的抽象，就是讓上層類只是代表了：我是一個事件源，或，我是一個監聽者！
二：老師布置作業的事件驅動模型版本
老規矩，讓我們先給出類圖：
然後，代碼實現之：
觀察者接口（學生）。由於在事件驅動模型中，只有一個沒有任何方法的接口，EventListener，所以，我們可以先實現一個自己的接口。為了跟上一篇的代碼保持一致，在該接口中我們聲明的方法的名字也叫update。註意，我們當然也可以不取這個名字，甚至還可以增加其它的方法聲明，全看我們的業務需要。
package com.zuikc.events;
import java.util.Observable;
public interface HomeworkListener extends java.util.EventListener {
public void update(HomeworkEventObject o, Object arg);
}
繼而實現觀察者類（學生），如下：
package com.zuikc.events;
public class Student implements HomeworkListener{
private String name;
public Student(String name){
this.name = name;
}
@Override
public void update(HomeworkEventObject o, Object arg) {
Teacher teacher = o.getTeacher();
System.out.printf("學生%s觀察到（實際是被通知）%s布置了作業《%s》 \n", this.name, teacher.getName(), arg);
}}
對比一下上篇，有變動沒？
繼而實現事件源這個類，如下：
package com.zuikc.events;
public class HomeworkEventObject extends java.util.EventObject {
public HomeworkEventObject(Object source) {
super(source);
}
public HomeworkEventObject(Teacher teacher) {
super(teacher);
}
public Teacher getTeacher(){
return (Teacher) super.getSource();
}}
在這個類中，指的關註的就是這個getTeacher方法，它封裝了父類EventObject的getSource方法。理論上，我們使用父類的getSource方法也可行，但是重新在子類封裝一下，可讀性更強一點。
然後呢，然後就是我們的教師類，如下：
package com.zuikc.events;
import java.util.*;
public class Teacher {
private String name;
private List<String> homeworks;
/*
* 教師類要維護一個自己監聽器（學生）的列表，為什麽？
* 在觀察者模式中，教師是被觀察者，繼承自java.util.Observable，Observable中含了這個列表
* 現在我們沒有這個列表了，所以要自己創建一個
*/
private Set<HomeworkListener> homeworkListenerList;public String getName() {
return this.name;
}public Teacher(String name) {
this.name = name;
this.homeworks = new ArrayList<String>();
this.homeworkListenerList = new HashSet<HomeworkListener>();
}public void setHomework(String homework) {
System.out.printf("%s布置了作業%s \n", this.name, homework);
homeworks.add(homework);
HomeworkEventObject event = new HomeworkEventObject(this);
/*
* 在觀察者模式中，我們直接調用Observable的notifyObservers來通知被觀察者
* 現在我們只能自己通知了~~
*/
for (HomeworkListener listener : homeworkListenerList) {
listener.update(event, homework);
}}
public void addObserver(HomeworkListener homeworkListener){
homeworkListenerList.add(homeworkListener);
}}
這個類稍微長了那麽一點點，有幾個地方值得註意：
第一處地方，Teacher沒有父類了，Teacher作為事件源中的Source被封裝到HomeworkEventObject中了。這沒有什麽不好的，業務對象和框架代碼隔離開來，解耦的非常好，但是正因為如此，我們需要在Teacher中自己維護一個Student的列表，於是，我們看到了homeworkListenerList這個變量。
第二處，在觀察者模式中，我們直接調用Observable的notifyObservers來通知被觀察者，現在我們只能靠自己了，於是我們看到了這段代碼，
for (HomeworkListener listener : homeworkListenerList) {
listener.update(event, homework);
}
這一點問題也沒有，我們繼續來看客戶端代碼吧：
package com.zuikc.events;
import java.util.EventListener;
public class Client {
public static void main(String[] args) {
Student student1= new Student("張三");
Student student2 = new Student("李四");
Teacher teacher1 = new Teacher("zuikc");
teacher1.addObserver(student1);
teacher1.addObserver(student2);
teacher1.setHomework("事件機制第二天作業");
}}
結果如下：
從客戶端的角度來說，我們幾乎完全沒有更改任何地方，跟觀察者模式的客戶端代碼一模一樣，但是內部的實現機制上，我們卻使用了事件機制。
現在我們來總結下，觀察者模式和事件驅動模型的幾個不同點：
1：事件源不再繼承任何模式或者模型本身的父類，徹底將業務代碼解耦出來；
2：在事件模型中，每個監聽者（觀察者）都需要實現一個自己的接口。沒錯，看看我們的鼠標事件，分表就有單擊、雙擊、移動等等的事件，這分別就是增加了代碼的靈活性；
不管怎麽說，我們用一堆小白代碼實現了一個事件驅動模型的樣例，雖然沒什麽實際用處，但也解釋了原理，接下來的一節，我們就要看看那些稍微復雜且看上去很有用的代碼了！
從零開始理解JAVA事件處理機制（2）