對於任何支援GUI的操作環境，系統無時無刻不在監聽這每一個滑鼠點選，按鍵這樣的事件，操作環境將這些事件報告給正在執行的應用程式。不同的程式語言有不同的處理事件的機制，像Visual basic 每個GUI元件都響應一個固定的事件集，不可能改變這個響應的事件集。而原始的C進行事件驅動的程式設計時，就需要不斷地檢查事件佇列，好處是不想Visual Basic那樣隱藏事件，響應的事件不收限制（具體現在還不知道是什麼，雖然以前很淺顯的學過硬體部分的ucos 作業系統）。而在Java中的AWT所知的事件範圍內，完全可以控制事件從事件源到事件監聽器的傳遞過程。不過，事實上，可以把任何物件指派給事件監聽器，但是事實上，還是選擇那些容易響應事件的物件。

  事件源：是一個能夠向自身註冊事件監聽器，當某個事件發生時，能向他所註冊的所有事件監聽器傳送通告的物件。

  事件監聽器：指實現了某個特定事件介面的類物件。

  事件：封裝了事件的資訊，包括對事件的說明和引數。

舉個JButton的例子

事件源 JButton 有一些向自己註冊監聽器的方法   註冊Mylistener監聽器。當事件發生時  將ActionEvent 物件傳遞到監聽器的actionPerformer()方法中

2.簡潔的指定監聽器

當介面中只有一個方法，當需要使用這個介面的物件時，就可以用lambda表示式。因此使用監聽器執行單獨的動作時，就可以使用lambda表示式。

多個動作就可以使用匿名類。

注意：有些程式設計師不善於使用匿名類和lambda表示式，而喜歡使用實現了監聽器介面的事件源容器，不建議這樣寫，我像大概是看起來複雜吧

3.介面卡類

介面卡：在程式設計中，介面卡是讓2個因介面不相容而不能一起工作的類一起工作。假如，根據初步需求建立了一個基類，而在開發過程中瞭解到了詳細需求或者說需求發生了改變，而開發的介面已經設計完畢，並且大規模的使用了。如果再想修改這個介面，就可能造成大規模重複性的修改，同時也可能產生因修改不完全造成的錯誤。這時就有了介面卡模式的出現。

在Java.awt中，實現了特定介面，就必須實現所有的方法，然而現在只需要使用個別的方法，書寫其他方法就是一種乏味的工作。因此Java為每個含有多個方法的awt事件監聽器介面都提供了一個介面卡類，這個類實現了介面中的所有 方法，但是什麼也沒做，自動滿足Java實現相關介面的技術要求。可以通過擴充套件介面卡類來完成對某事件的響應動作

4.awt事件繼承層次

所有的事件都是派生於  Java.util.EventObject類。而eventqueue有一個子類AWTObject。所有AWT事件類的父類。而有些swing元件可能生成其它型別的事件

有些事件類，Java程式設計師並不會實際的使用它們，paintEvent物件插入事件佇列，並不會傳遞給事件監聽器