java 事件处理机制

java 事件处理机制概要:
通用（一般）机制——实现接口:
1. 首先确定要监听的对象和事件
2. 其次确定监听者及其要实现的接口及要重写的方法 (具体完成事件响应的方法,即事件最终会传至的方法),[监听者一般为被监听者本身(如窗体)或直接包含被监听者的对象,这样可以较好地实现封装；且对于需要当前类的对象响应的事件,这是解决问题的唯一方法]。而对于系统响应事件，则也可以采用外部类来监听(并不常用),这通常由adapter 类的子类来完成（尽管实现接口也完全可以达到目的,但需要覆盖所有方法）。
虽然说自我监听是最符合OOP封装精神的，但却并不简便，比如继承一个Button类，来实现自我监听是有些烦琐的。而Frame类很少“裸奔”，用其来监听是一种明智、高效、易实现、且不是特别背离OOP封装原则的做法。
4. 最后在合适的方法(含构造函数---较常用)中的适当位置创建监听者对象,并为要监听的对象添加该对象.
//-------------------------------------------------------------------------------------------------------------------------------------------
补充机制——adapter类继承
两种用法:
1.直接为被监听对象添加adapte类的实例作为监听者，在添加的同时重写对应的方法；这样看起来，监听方法和被监听对象及其同层对象似乎处在同一层次，那么该方法可以直接访问这些对象吗？答案是肯定的，这也是这种用法和第二种用法的区别所在。因此在实践中，大多采用这种方法。而第二种途径在处理多个被监听者，同一响应的情况时比较简便。
2.创建一个继承adapter的类，在其中重写需要的方法，在合适的地方添加该类的实例,只能处理系统响应事件。
//----------------------------------------------------
总结:
对于当前类中的对象响应的事件[非系统对象(如system)响应事件]，只能用当前类对象(this)监听;具体途径有两种，一种是实现对应接口（可以多个）,但必须覆盖接口中的所有方法；另一种是继承对应的adapter 类（只能一个），可以只覆盖需要的方法，为了弥补“只能一个”的不足,java提供了一种巧妙的机制,即在适当的方法中直接为被监听对象添加adapter类的实例作为监听者，并在添加的同时覆盖需要的方法，这样既可以处理当前类中的对象响应的事件,又可以实现adapter类的"类似多继承"(java中没有提供类似C++中的真正的多继承机制，如果有了多继承，这种机制就可以不要了，但多继承不符合真实世界的逻辑，且会增加内存的负担，接口可以多继承，是因为接口中不含变量)。
对于系统类对象响应的事件，既可以用与上面相同的方法，也可以用实现对应接口或adapter的外部类对象监听。
//----------------------------------------------------
在事件处理过程中涉及三类对象，一类是引发事件的对象，也就被监听者,需要为其添加监听者；另一类是事件的处理者，也就是监听者，需要在其内部实现（覆盖）对应(响应)事件的方法，并在方法中访问最终完成事件响应的对象（响应对象）；第三类就是响应对象。
java事件处理：只能使用响应对象对其可见的对象（即可以访问响应对象的类）来做为监听器，如：
1.如果响应对象是系统，因其对所有对象（类）可见，所以可以用任何类来监听;
2.如果响应对象是某一对象(类)内部包含的私有对象，因其只对该外部对象和该外部对象的内部类（含局部类）可见，只能用这个外部对象（类）或外部对象的内部类的对象来做为监听器。如果是对外部可见的对象，则可以用外部其它的类来做为监听器。
3.如果某类中的对象引发的事件由另外一个类中的私有对象响应，则只能用另外一个类的对象来监听,而不能用另一个类的内部类来监听，因为这时这个内部类的外部类的对象并不一定创建，即使创建了也未与这个内部类建立任何关系，这是由内部类的本质决定的。

一、OOP中的几种关系 1.组合关系：将多个类的实例（对象）组合到一个更大的类（对象）中，这多个类之间是并列的关系（地位），它们之间不可以相互控制（即改变彼此的状态），但可以相互调用。而包含它们的类可以通过它的方法来直接控制它们的行为,间接控制它们的状态（之所以说间接是因为按照OOP的封装和安全原则，各个对象都是要通过其自有的方法来控制其自身的状态）。 2.继承和实现关系 3.实例化 4.局部变量（对象）只能由其所在的方法控制。 二、 java 中main()方法不受任何对象支配，且只能有一个,所以主类只能有一个实例.