JAVA应用程序设计开发

lastwinner

　　15.2 事件机制
　　作为一个组件，其自身的事件处理以及与其他组件的交互无疑是一个重点。一个豆要实现它的功能，事件处理是核心。本节介绍Java豆的事件机制。

　　15.2.1 Java豆的事件机制
　　Java豆的事件机制，就是把对象的状态改变通知给其它相关对象以进行适当处理的机制。当一个对象激发了某个事件（如鼠标点击、键盘操作）时，如何做出响应呢？这一节我们来讨论这一过程的细节。

　　⒈基本模型

　　假如有对象a为类A的实例，对象b为类B的实例。程序的功能要求，当a激发了一个事件e时，b要作出相应的反应。因而就有下面的过程(如图15.4)。

　　　　
　　　　　　　　图15.4 事件模型㈠

　　上面这一过程看起来很自然，但存在两个问题：(1)当事件e发生时，对象a如何知道它将把事件给谁？(2)对象a可能激发的事件假如有很多，如何安排响应者(监听者b)？如果对每个事件都对应一个监听者，显然对象数目就太多了。

　　对上面两个问题，Java豆的解决方案是这样的：

　　(1)每一类事件由一个方法来处理，而同族的事件被组织成一个监听者接口。实现这一接口的类便可处理对应的事件，其对象就是监听者对象。

　　例如，鼠标点击(Click)和双击(Double Click)是两类事件，由于发生原因近似，我们可以定义一个接口来组织它们，形如：

　　public interface MouseActionListener extends java.util.EventListener{
　　　　public void mouseClick(MouseActionEvent e);
　　　　public void mouseDoubleClick(MouseActionEvent e);
　　}

　　(2)事件的有关信息也需封装起来成为类，传递给监听者，以便响应事件时使用。这种事件类是java.util.EventObject的子类。就像异常(Evception)类的各子类一样，有的事件类之所以被创建仅是为提供不同种类的事件状态的逻辑划分，而未必具有独有的数据。换句话说，有的事件仅提供一个形式。如上面接口中的MouseActionEvent可以这样定义：

　　public class MouseActionEvent extends java.util.EventObject{
　　　　public MouseActionEvent(java.awt.Component src){
　　　　　　super(src);
　　　　}
　　}

　　如上这种封装事件有关信息的类称为事件状态类(EventState Class)，其实例为事件状态对象。

　　由此我们可以定义一个监听者类B，监听鼠标点击/双击事件：

　　Class B implements MouseActionsListener{
　　　　public void mouseClick(MouseActionEvent e){
　　　　　　//...处理点击事件
　　　　}
　　　　public void mouseDoubleClick(MouseActionEvent e){
　　　　　　//...处理双击事件
　　　　}
　　　　//...类中其它数据和方法
　　}

　　至此，前面的第二个问题已经解决了。也就是说，不必对每一类事件对应一个监听者，而是用接口把同族的事件分组，而以实现该接口的类作为几类同族事件的共同监听者。

　　但第一个问题仍然是悬而未决：如果有超过一个的对象都发生了鼠标点击/双击事件，它们如何把事件递给真正相关的监听者呢？这就要用到“监听者登记”技术了。

　　Java豆的应用程序接口说明中指出：“为使潜在的诸事件监听者能与正确的事件源实例登记，以便建立从源到监听者的事件流，事件源类应提供登记与注销的方法。”

　　这就是说，事件源对象应包含登记与注销监听者的方法，执行登记方法后，就将源与监听者联系了起来 ；待这种联系不再必要时，还可以注销掉。仍以前面的例子为例，作为事件源的A必须有这样的方法：

　　class A{
　　　　public void addMouseActionListener(MouseActionListener l){
　　　　　　//实现细节
　　　　}
　　　　public void removeMouseActionListener(MouseActionListener l){
　　　　　　//...实现细节
　　　　}
　　　　//...其它成员数据和方法
　　}

　　然后，需要建立对象a、b之间的关系时，用

　　a.addMouseActionListener(b);

就可以完成登记过程。而当特定时刻后不再需要b来监听a的事件时，又可用

　　a.removeMouseActionListener(b);

来注销前面的登记。

　　综合上述关于监听者、事件源、事件状态关系，我们可以得到下面这张联动关系图（图15.5）。为了节省篇幅，类A的定义中只列出了登记监听者方法，类B的定义中也只列出了一个方法。

　　　　
　　　　　　　　图15.5 事件模型㈡

　　上图中需要解释的是如何决定b应调用哪个方法来响应事件。这个工作不是由b来完成的，而是由a。事实上是由事件源对象分辨同族事件的种类，并调用监听者的相应方法的。15.2.2之2将给出这一过程的实现。

　　由上图进行抽象可以得到基本事件模型的图示(图15.6)。

　　　　
　　　　　　　　图15.6 事件模型㈢

　　总而言之，Java豆的基本事件模型有以下几个要点：

　　(1)激发事件的对象，即事件源对象，它们的定义中包括特定的登记监听者和注销监听者的方法，以便与相应的监听者对象相联系。

　　(2)每一类事件通知(notification)被定义成方法，相近的方法由事件监听者接口分别组织起来。事件监听者接口由java.util.EventListener继承而来。

　　(3)事件监听者类通过实现某些接口来确定它们对何种事件感兴趣。

　　(4)与某事件通知有关的信息被封装于事件状态对象中，该对象的类由java.util.EventObject继承而来，作为一个唯一的参数传递给事件方法。

　　(5)对事件的响应是由监听者对象的方法调用实现的。

　　读者可根据这几点对照前面的例子，以加深对基本事件模型的理解。

　　⒉编程中的命名规则

　　Java豆是可以在应用创建工具被可视化操纵的组件，这就要求创建工具对豆的性质和行为有充分的了解。以节15.1.1的例2为例，第(8)、(9)步中，我们将OurButton对象的actionPerformed()方法与Juggler对象的stopJuggling()方法联系起来，其中的内在联系是：

　　(1)OurButton类定义了addActionListener(ActionListener l)方法。

　　(2)ActionListener接口中定义了方法actionPerformed(ActionEvent e)。

　　(3)Juggler类中有方法stopJuggling(ActionEvent e)。

创建工具BDK就是分析出了各类所具有的相应方法，从而能够将这两个豆组装在一起。

　　为了使创建工具能够机械地识别豆的性质和行为，我们编程时要遵循一定的命名规则。不仅在事件模型中，而且在属性的修改、关联时都要遵循一定的规则。将在涉及到这些内容时将分别予以介绍。

　　对于基本事件模型，命名的规则是：

　　(1)事件状态类往往以“**Event”命名，“**”表示任意字符串，如MouseActionEvent，KeyEvent等。

　　(2)监听者接口往往以“**Listener”命名，如“ActionListener”。

　　(3)事件源类中的登记和注销监听者的方法按如下定义：

　　public void add<监听者接口名>（<监听者接口名>listener）；

　　public void remove<监听者接口名>(<监听者接口名>listener)；

　　如addActionListener(ActionListener l)暗示着存在一个监听者接口ActionListener。

　　注意，为了防止多线程代码中的竞争，登记、注销监听者的方法常常是同步的。也就是说，要加上“synchronized”修饰符。

　　(4)创建工具在事件发生后要将事件传递给监听者。因而，监听者处理事件的方法（即监听者接口中定义的方法）一般要以该事件类的实例作为参数，哪怕这一事件的信息在作出响应时可能并不需要。

　　(5)为事件源编写登记、注销的方法时，优先利用该事件源类自父类继承来的方法（如java.awt.Component类有addFocusListener()方法），尽量不另外创建新的方法。这样所编写的代码易读、标准，也省去设计接口的麻烦。当然，如果现有的方法和监听者接口不能满足需要，就必须另外编写了。

lastwinner

　　⒊事件模型的扩展

　　(Ⅰ)适配器(Adapter)

　　基本事件模型说明了事件源与监听者之间的联动关系，然而，仅有这个基本模型是不够的。当事件的传递和响应中需要一些附加的工作，或者按基本模型不能编写出适合要求的监听者时，需要引入适配器对象。

　　考虑节15.1.1的例2，要实现按钮与Juggler的控制关系，如以基本模型来考虑，就至少应有下面的条件：

　　(1)按钮OurButton的类中有addActionListener()方法；

　　(2)Juggler类实现了ActionListener接口。

这样，当按钮被点击，OurButton就激活了一个ActionEvent事件。如果Juggler类实现了ActionListener接口，就会执行它的actionPerformed()方法(actionPerformed()是ActionListener接口包含的唯一方法)，从而实现响应。然而，Juggler是一个已编写好的类，而且没有实现actionListener接口。那么这两个豆是如何联系起来的呢？

　　这个问题并不难解决。假如我们是要把两个豆在手写的程序中组合起来，那么我们可以手工编写一个中介类。它实现ActionListener接口，而在方法actionPerformed()的实现中，调用Juggler的适当方法，比如，对这个例子可以编写：

　　Class MyAdapter implements ActionListener{
　　　　//...其它信息
　　　　public void actionPerformed(ActionEvent e){
　　　　　　juggler.startJuggling(e);
　　　　}
　　}

　　其中，juggler是Juggler类的对象。而事件源要登记监听者时，应登记：

　　OurButton btn=new OurButton();

　　btn.addActionListener(new MyAdapter());

这样，即可完成两个豆的联动。

　　这里的中介类MyAdapter就是一个“适配器”类。顾名思义，适配器就是充当桥梁和纽带作用的。从功能上说，适配器并不是真正的监听者，它只是在事件源与监听者之间搭了一座桥。真正的监听者类并未实现监听者接口，而是经过适配器的传递作出反应。以上例为例，Juggler对象是真正的监听者对象，而MyAdapter类的实例是适配器对象。

　　加入适配器后的事件模型示意图如下(图15.7)

　　　　
　　　　　　　　图15.7 含适配器的事件模型

　　事实上，BDK和应用创建工具也往往采用标准的适配器来完成豆的联接。如我们在BDK中组合OurButton和Juggler豆时，OurButton类激发的事件是ActionEvent对象，则缺省适配器就会实现ActionListener接口，以提供恰当的中介。

　　适配器是Java豆事件模型中极端重要的一方面。适配器可以针对一族事件，也可以针对多族事件，前者如前面的例子，后者也很简单，只要使适配器类实现多个监听者接口就可以了。

　　(Ⅱ)有任意参数表的事件方法

　　前面提到的各种监听者接口中，无论定义何种方法（即事件方法），其参数都是唯一的，即参数是一个事件对象，它的类是java.util.EventObject的子类。

　　在特殊情况下，允许放宽这一限制，即事件方法可以有有限多个参数。比如与其它语言接口时，或者某些实现场合要求方法必须有多个参数时可以这样做。应用创建工具应能支持这样的事件方法。但这种不标准的事件方法应尽量避免使用，而是以标准形式与适配器的组合来实现其功能要求。

　　(Ⅲ)多匹配与单一匹配(Muliticast and Unicast)

　　所谓多匹配与单一匹配的问题，是指对于同一类事件允许有几个监听者监听的问题。一般的事件发送是多匹配的，也就是说，对每一类事件可以有多个监听者来监听。例子是我们可以用一个按钮来控制两个Juggler对象，按动一次而使两个动画都开始。

　　但在有此情况下，应用将要求某一事件仅能由一个监听器来监听，这种情形与上一种情形的不同在于事件源的登记监听器方法的不同。该情形下登记监听器方法的形式为：

　　public void add(监听者接口名)(<监听者接口名>listener) throws java.util.TooManyListenersException

如果发生了企图登记一个以上监听者的情况，将抛出TooManyListenersException异常。

　　另外，如果以null作为参数调用登记方法，无论在多匹配还是单一匹配的情况下，都是不合法的，将引发IllegalArgumentException异常或NullPointerException异常。

　　(Ⅳ)并发控制

　　在多线程环境下，事件控制极易引发竞争和死锁。在必要的场合，需要使用synchronized修饰符。为了避免死锁，又要尽量用“同步块”来代替整个同步方法。如本章后面将讲到的例子中有这样一段代码：

　　...

　　Vector l;
　　if(cmd.equals("+"){
　　　　setValue(getValue()+1);
　　　　ActionEvent e = new ActionEvent(this,0,null);
　　　　synchronized(this){
　　　　　　l=(vector)listeners.clone();//同步块
　　　　}
　　...

这就是以同步块而非同步方法实现事件控制的过程。

lastwinner

　　15.2.2 编程实现

　　节15.2.1中，给出了有关方法的原型而未给出具体的实现。这一节讨论事件机制的程序实现。

　　1.监听者的登记和注销

　　事件监听者一旦登记，一般是存入一个向量(Vector)。但对于关联属性与受限属性(节15.3)的改变事件，java.beans类库中另提供了两个类PropertyChangeSupport与VetoableChangeSupport来存储登记的监听者。对于一般的监听者，登记时只要将它放入一个向量即可。如对于节15.2.1提到的例子可以这样实现：

　　public class A{
　　　　public synchronized void addMouseActionListener(MouseActionListener l)
　　　　　　listeners.addElement(l);
　　　　}
　　　　public synchronized void removeMouseActionListener(MouseActionListener l){
　　　　　　listeners.removeElement(l);
　　　　}
　　　　//...其它方法
　　　　private Vector listeners = new Vector();//向量，存储监听者
　　}

　　2.事件的激发与处理

　　前面提过，事件的分析与处理实际上是由事件源来完成的。这一过程在旧的事件模型中，在handleEvent()方法中实现；在新的事件模型中，则表现为事件源类（或适配器）实现若干事件监听者接口（如WindowListener,MouseListener），在该接口的方法中做分析处理事件的工作。但无论在哪种情况下，要做的工作都是一样的，大致有：

　　(1)复制一个存储监听者的向量；

　　(2)创建事件状态对象，以备传递；

　　(3)对已登记的所有事件监听者，分别调用它们的事件处理方法。

　　仍以前面有的例子为例，对鼠标点击事件的处理为：

...
Vector l;//声明一个向量，以备复制监听者存储向量
...//判断事件鼠标为点击事件，具体过程略
MouseActionEvent l = new MouseActionEvent(this);
//创建一个事件，以备传递，MouseActionEvent的定义见（节15.2.1之1）
synchronized(this){
　　l=(Vector)listeners.clone();//复制一个存储监听者的向量
//复制向量 listeners时之所以采用同步块是为了避免多线程方式下对listeners的读写导致
//错误。为了减少死锁的发生，这里采用同步块，而不是把该方法作成同步方法。
for (int i=0;i<l.size();i++){
　　MouseActionListener mal=(MouseActionListener)l.elementAt(i);
mal.mouseClick(e);
}//对登记的若干个MouseActionListener对象分别进行处理，调用其处理该事件的方法
//mouseClick()。
...

　　以上是分析处理事件的模式。可见，“传递事件”是指调用监听者适配器的方法而以事件作为参数。

　　在节15.6中给出的两个Java豆的完整例子中，读者可以看到上述实现细节的具体使用。

　　本节介绍了Java豆的事件机制。这是实现应用功能的核心部分，希望读者认真领会，并参照BDK提供的其它例子学习。

lastwinner

　　15.3 豆的属性(Properties)

　　属性可以影响豆的外观和行为。比如，一个可视的豆的背景色、前景色都是属性。节15.1例子中，Juggler豆的动画速率(animationRate)是属性；BDK附带的JDBC SELECT 豆的“URL”也是属性。每当你在BDK中选中一个豆，都可以在PropertySheet窗口中看到其可修改的属性。

　　Java豆的属性可以是各种类型的，或是各种类的实例。要访问一个属性，需要调用它所在类的访问方法(access method)。这些方法可分为读(get)和写（set)两类。为了BDK及其它创建工具能够自动分析出豆所具的属性，访问方法也有固定的命名规则。

　　即使在BDK的PropertySheet窗口中直接修改属性，属性也还是通过调用访问方法来修改。因而在开发Java豆的时候，就要编写适当的访问方法来读/写属性。对属性的写操作往往会有一些副作用，如导致豆被重画等等。

　　下面我们来介绍属性及其访问方法。

　　15.3.1 访问方法的命名规则
　　对于简单的属性（即指仅包含一个数据域的属性），命名规则为：

　　(1)读方法：<属性类型>get<属性名>()

　　如：Color getBackGroundColor()；

　　(2)写方法：void set<属性名>(<属性类型>value)；

　　如：void setBackGroundColor(Color value)；

上面两个方法访问一个名字叫BackGroundColor的属性，该属性的类为Color。

　　对于数组型的属性（我们称之为“下标属性”，即“indexed properties”），命名规则略有不同。下标属性涉及一组值，在访问时要指明需要的具体是什么。目前，Java豆要求下标必须为整形(int)。

　　对下标属性的访问方法有两种，其一是对整个数组同时访问，其二是只访问单个的下标变量。命名规则分别为：

　　(1)读整个数组：<单个属性类型>[] get<属性名>()；

　　如：Color[] getColors()；

　　(2)读单个元素：<单个属性类型> get<属性名>(int index)；

　　(3)写整个数组：void set<属性名>（<属性类型> values[]）；

　　(4)写单个元素：void set<属性名> (int index，<属性类型> value)；

　　这些方法在数组越界时会抛出java.lang.ArrayIndexOutOfBoundsException异常。无论对简单属性还是下标属性，访问方法都可以抛出异常，就像其它方法一样。

lastwinner

　　15.3.2 关联属性(Bound Properties)
　　关联属性的演示在节15.1的例一中已经出现了。引入关联属性的用意是显然的，即当一个豆属性发生改变时，可以把这个变化通知给其他对此感兴趣的豆或容纳该豆的容器，以使它们作出适当的反应。关联属性的变化不仅仅可以引发某个豆对应的某个属性发生变化。看了下面的分析读者就会知道，关联属性的变化也是激发了一个事件，而事件的监听者（或有适配器情况下的实际监听者）监听到事件变化后可以作出各自相应的反应，改变自已的对应属性仅是反应的一种而已。

　　类库java.beans(BDK 及JDK1.1版中均有)中，包含了与关联属性相关的接口与类。编程时使用它们就可以完成对属性改变的处理。整个作用过程也与一般的事件处理相似。不同的是，用来存储“属性改变监听者”（PropertyChangeListener）的不是一个向量，而是类库提供的PropertyChangeSupport类的对象。另外，类库还提供了PropertyChangeListener接口与PropertyChangeEvent类，分别作为监听者接口和事件状态类使用。

　　类似节15.2.2，关联属性的编程实现是：

　　(1)监听者登记/注销

　　public void addPropertyChangeListener(PropertyChangeListener l){
　　　　changes.addPropertyChangeListener(l);
　　}
　　public void removePropertyChangeListener(PropertyChangeListener l){
　　　　changes.removePropertyChangeListaer(l);
　　}
　　private PropertyChangeSupport changes = new PropertyChangeSupport(this);

上面这些代码一般可以不加任何修改而直接用在程序中。

　　(2)事件的激发和处理

　　由于事件是在修改属性时发生的，因此事件的创建和传递在相应属性的写方法中进行。而且，PropertyChangeSupport类已为我们提供了触发事件的方法，这使我们不必一一寻找监听者并调用其方法。具体的作法是：

　　public void set(<属性类型> value){
　　　　创建一个该属性类型的变量或对象，不妨记为oldValue；
　　　　oldValue = 属性值；
　　　　对属性赋以新值value；
　　　　changes.firePropertyChange("<属性名>"，oldValue，value)；
　　}

　　如果属性是基本类型的(如int)，则在调用firePropertyChange时，仅用oldValue、value是不够的，需要把它包装成类对象，如：

　　changes.firePropertyChange("<属性名>",new Integer(oldValue),new Integer(value));

　　注意，先修改了属性的值，然后激发相应的属性改变事件。

　　对于属性事件的监听者来说，它只需实现PropertyChangeListener接口，在这个接口中仅有一个抽象方法

　　public abstract void propertyChange(PropertyChangeEvent evt)

在PropertyChangeEvent类中封装了激发该事件的对象（事件源对象），属性原值，属性新值，属性名等信息，可以用相应的方法读取。于是监听者就可以根据属性的变化作出相应的反应。

　　除了节15.1.1的例子之外，BDK中的ChangeReporter豆也是关于关联属性的。将一个豆A的propertyChange事件与ChangeReporter豆的reportChange方法联系起来，修改A的属性，ChangeReporter就会显示属性名及其新值，读者不妨自己实验一下。

lastwinner

　　15.3.3 受限属性(Constrained Properties)
　　某些时候，豆的一些属性是不希望被改变的。或者，是否修改需要经过其它豆或容纳该豆的容器来判断，这些属性称为受限属性。受限属性实现也很简单，即在修改属性之前激发一个受限属性的改变事件，如果不发生异常，则继续其修改工作，改变属性值；若由于其它豆的干预而产生了异常，就不进行修改。

　　java.beans类库中也提供了相关的类和接口。VetoableChangeListener接口是受限属性改变监听者接口，并提供激发属性改变事件的方法，这一方法可能抛出受限属性改变异常PropertyVetoException。异常类PropertyVetoException中封装了描述信息，并提供了获取相应属性改变事件的方法。

　　受限属性的实现与关联属性基本相同，但激发事件是在修改属性之前。

　　(1)属性的登记/注销

　　private VetoableChangeSupport vetos = new VetoableChangeSupport(this);

　　public void addVetoableChangeListener(VetoableChangeListener l){

　　vetos.addVetoableChangeListener(l);

　　}

　　public void removeVetoableChangeListener(VetoableChangeListener l){

　　vetos.removeVetoableChangeListener(l);

　　}

　　(2)事件激发和处理

　　下面的方法修改一个受限的关联属性。在修改属性值之前，先激发一个受限属性改变事件，修改之后，再激发一个关联属性改变事件。注意此方法可能抛出的异常。

public void set <属性名>(<属性类型> value) throws PropertyVetoException{

　　创建一个该属性类型的变量或对象oldValue;

　　oldValue = 属性值；

　　vetos.fireVetoableChange("<属性名>",oldValue,value);

　　对属性赋以新值value;

　　changes.firePropertyChange("<属性名>",oldValue,value);

}

受限属性改变事件的监听者只需要实现VetoableChangeListener接口，即实现

public abstract void vetoableChange(PropertyChangeEvent evt) throws PropertyVetoException

方法，即可处理该事件。

　　BDK中提供的Voter类提供对象受限属性的处理。将JellyBean的vetoableChange事件与Voter豆的VetoableChange方法相关联，并改变受限属性priceInCents，看发生的现象。改变Voter类的vetoAll属性后，再改变priceInCents，看有什么改变。这可以给读者一个感性认识。

lastwinner

　　15.4 定制(Customize)
　　Java豆是一种可重用的软件组件，为了达到多次重用的目的，Java豆就要有一定的通用性。因此，在实际使用时，需要对豆的外观、行为作一定的修改，使之符合需要，这一修改过程称为定制。

　　定制的方法有两种，第一种是用PropertySheet来完成的，这种方法我们已经很熟悉了。另一种方法是编写豆的Customizer类，用这个类来完成复杂属性的修改、行为的设定。第一种方法适用于中小规模的豆，而后一种方法较为灵活，能够处理较为复杂的情况。

　　为了获得一些感性认识，让我们把BDK运行起来，在BeanBox中放置一个JDBC SELECT 豆，点击Edit菜单中Customize...项，可以看到一个定制器（Customizer）窗口。

　　无论是定制器还是属性表单窗口，基本的组成都是若干个项，每个项对应一个属性。属性有各自不同的编辑方式。对于一些常用的属性，BDK提供了相应的编辑器(Editor)。在BeanBox中选中JDBC SELECT 豆，然后点击PropertySheet中的foreground项，可以看到一个新窗口ColorEditor。这就是BDK为Color对象提供的编辑器。如果开发豆时引入了新的类型，开发人员应附带开发相应的编辑器。

　　那么，如何使BDK或创建工具明白用什么编辑器来编辑某一类型的属性呢？Java豆的“属性编辑器管理器”(PropertyEditor Manager)可以完成这一工作，该类中的方法

　　public static void registerEditor(Class targetType,Class editorClass)

　　使特定类型可以与它的编辑器联系一起。

　　当遇到一个类型时，BDK按下列规则来搜索属性编辑器：

　　(1)首先寻找有无显式注册的编辑器（注：Java的基本类型如int,bookean等的编辑器已预先注册）。

　　(2)其次寻找给定属性类型加“Editor”构成名字的编辑器类，如，当遇到属性类为abc.cde.Fgh时，将寻找有无abc.cde.FghEditor。

　　(3)最后，将在给定的类搜寻表中这样的类：其名字为属性类名的最后一节加上“Editor”。所谓给定的类搜寻表是指BDK对编辑器的搜索路径，一般是java.beans.editors，故对abc.cde.Fgh将寻找java.beans.editors.FghEditor。

　　当一个编辑器修改了某个值时，它将激发一个PropertyChange事件，事件的接收者（如创建工具）检测到事件后，根据新值，调用相应属性的写方法完成对目标的修改。

　　编辑器对豆的修改应是间接的，即并非直接修改目标对象，而是创建一个新的对象，对它进行修改。当修改完毕激发了PropertyChange事件后，事件接收者将检索这一新的对象，根据它作对目标对象的修改。

　　属性的定制器Customizer的命名规则为<Java豆名>Customizer，它必须是java.awt.Component的子孙类，并实现java.beans.Customizer接口，它应是一个独立的对话窗口。

　　Customizer接口中有三个方法：addPropertyChangeListener()方法，removePropertyChangeListener()方法和setObject()方法。其中public abstract void setObject(Object bean)方法用以设置被定制的豆，该方法只能调用一次。

　　节15.6例2中编写了一个简单的属性定制器，它是由BeanInfo类通知给BDK的（参见节15.5）。BDK一旦得知某个豆有定制器，就会在BeanBox的Edit菜单中加一项“Customize...”。点击它，便可显示出相应的定制窗口，读者可以从节15.6例2中大致了解其实现过程。

lastwinner

　　15.5 自省(Introspection)
　　所谓“自省”是指创建工具了解豆具有何种属性及行为的过程。Java豆要求能在创建工具中被可视化地操纵，当然也就要求创建工具能够分析出豆的属性、行为。这个分析过程也有两条途径可走。一种是低级的“反映”(reflection)机制，另一种是较为高级的，即由豆的开发者提供一个类来提供描述豆的信息。

　　15.5.1 反映机制
　　反映机制说起来不复杂。它是依赖命名规则与类的继承关系来完成工作的。前面曾经数次提到了命名规则的问题。要求编程人员遵循标准命名规则，就是为了方便反映机制的实施。

　　对于每一对匹配的get<属性名>、set<属性名>方法(所谓匹配是指方法名中的“<属性名>”相同，且get方法的返值与set方法的参数为同一类型)，则认为被考察豆有可读写属性，名字即<属性名>。如果仅有一个方法get<属性名>（或set<属性名>），则认为被考察豆有一个只读（只写）属性。

　　布尔型的属性与其它属性稍有不同，它的读方法是：

　　public boolean is<属性名>();

这个方法可用来取代get方法，也可以与get方法共存。

　　类似地，下标属性的读写方法也说明了豆具有下标属性。如，一对方法

　　public <属性元素> get <属性名> （int a）；

　　public void set<属性名> (int a,<属性元素> b);

说明了一属性，其类型为数组<属性元素>[]。

　　2.分析事件

　　对于每一对add<监听者> （<监听者> l）和remove<监听者>（<监听者> l）方法，反映机制将确定存在一个事件监听者，如果add方法不抛出java.util.TooManyListenerExecption，则认为它是多匹配监听者，否则，，视作单匹配监听者。

　　对方法而言，认为所有的public方法缺省地是可从外部引用的方法。

　　了解了上述反映机制的基本内容之后，我们自己开发程序时就要注意命名的问题，以使创建工具对我们开发的Java豆有正确的分析。

lastwinner

　　15.5.2 BeanInfo类
　　如果我们想隐藏豆的一些属性和行为，或者改变它们在创建工具中的显示，我们可以用一个类BeanInfo来说明豆的属性和行为。这个类可以为豆引入图标、定制器(Custimizer)，可以改变BeanBox中一个被选中的豆对应的EDIT|Events菜单项的内容。加入这个类，等于给豆添加了一层面纱；尽管具体的实现没有变，却可以改变其外观。
　　java.beans类库提供了接口BeanInfo和类SimpleBeanInfo来帮助我们完成这一工作。它们当中有一些主要的方法，简介如下：
　　*public BeanDescriptor getBeanDescriptor();
　　提供豆与定制器的有关信息。
　　*public propertyDescriptor[] getPropertyDescriptors();
　　提供豆的属性信息。
　　*public EventSetDescriptor[] getEventSetDescriptors();
　　提供豆的事件信息。
　　*public Image getIcon(int iconkind)
　　提供豆的图标。
　　我们可以重载这些方法来提供豆的有关信息。其它还有一些方法就不一一叙述了，读者可以参阅BDK类库文档。
　　在节15.6例二中提供了一个BeanInfo类的简单例子，供读者参考。
　　当一个豆被创建工具分析时，创建工具将沿它的继承关系链寻找各级类是否存在相应BeanInfo类(BeanInfo类的通常命名是<豆名>BeanInfo)，从而找到开发者对豆的显式说明。找不到时，则利用低级的反映机制来分析豆的属性和行为。

lastwinner

　　15.6 程序示例
　　本节中讲解两个例子，以示意Java豆的编程。

　　示例OvalDemo。

　　这个例子的功能是在一块区域内(150×150象素) 显示指定多个椭圆。用随机数来产生椭圆的位置和大小参数，例子中编写了椭圆个数和颜色两个属性。此外，还提供了增加一个椭圆和减少一个椭圆方法。为了简单起见，我们不关心它由父类继承来的其它属性和事件情况。这个豆提供了登记和注销PropertyChangeListener的方法。

　　这个豆只由一个类OvalDemo构成（例15.1）

　　例15.1 OvalDemo.java。

　　1ackage mybeans.ovals;

　　2:import java.awt.*;

　　3:import java.awt.event.*;

　　4:import java.util.Vector;

　　5:import java.util.Random;

　　6:import java.beans.*;

　　7ublic class OvalDemo extends Canvas{

　　//变量定义

　　//椭圆个数

　　8rivate int ovalNumber=5;

　　//用于产生随机数的变量

　　9rivate Random rd=new Random();

　　//椭圆颜色

　　10rivate Color forGroundColor = Color.blue;

　　//存储监听者的对象

　　11rivate PropertyChangeSupport changes=new PropertyChangeSupport(this);

　　12:

　　13ublic OvalDemo(){

　　14:super();

　　15:setSize(150,150);

　　16:}

　　17: public void paint(Graphics g){

　　18: g.setColor(foreGroundColor);

　　19: int hx,hy,tx,ty;

　　//产生随机数绘制椭圆

　　20: for(int i=0;i<ovalNumber;i++){

　　21: hx=Math.abs(rd.nextInt())%75;

　　22: hy=Math.abs(rd.nextInt())%75;

　　23: while((tx=Math.abs(rd.nextInt())%75)==hx);

　　24: while((ty=Math.abs(rd.nextInt())%75)==hy);

　　25: g.drawOval(hx,hy,tx,ty);

　　26: }

　　27:}

　　//增加一个椭圆

　　28: public void oneMore(ActionEvent e){

　　29: ovalNumberi++;

　　30: repaint();

　　31:}

　　//减少一个椭圆

　　32: public void oneLess(ActionEvent e){

　　33: ovalNumber--;

　　34: repaint();

　　35: }

　　//登记监听者

　　36: public void addPropertyChangeListener(PropertyChangeListener l){

　　37: changes.addPropertyChangeListener(l);

　　38: }

　　//注销监听者

　　39: public void removePropertyChangeListener(PropertyChangeListener l){

　　40: changes.removePropertyChangeListener(l);

　　41: }

　　//读属性OvalNumber

　　42: public int getOvalNumber(){

　　43: return ovalNumber;

　　44: }

　　//写属性OvalNumber

　　45: public void setOvalNumber(int num){

　　46: ovalNumber=num;

　　47: repaint();

　　48: }

　　//读属性Color

　　49: public Color getColor(){

　　50: return forGroundColor;

　　51: }

　　//写属性Color

　　52: public void setColor(Color newColor){

　　53：Color oldColor = foreGroundColor;

　　54: foreGroundColor = newColor;

　　55: changes.firePropertyChange("color",oldColor,newColor);

　　56: repaint();

　　57: }

　　58:}

　　现在我们分析一下这个示例。

　　第8～11行是变量说明，其中ovalNumber是椭圆的个数，rd用来产生随机数，foreGroundColor是椭圆的颜色。而changes，根据15.3，易知是用于存储PropertyChangeListener的。第17～27行是paint方法，它用随机数发生器产生ovalNumber个椭圆的参数，并将它们绘制出来。

　　第28～35行是两个方法，功能是增加/减少一个椭圆。它们的参数为ActionEvent型，在后面我们可以看到它与例2中WhirlButton豆连接的效果。

　　第36～41是登录和注销监听者的方法，这在15.3中已有说明。

　　第42～48行是对ovalNumber属性的读写方法。第49～57行是对color属性的读写方法。在后者的写方法中激发了PropertyChange事件，使得其它豆及豆的容器可以体察到color的变化。应该指出，对所有的属性，写方法一般都应激发PropertyChange事件，这里之所以在ovalNumber属性的写方法中不加这一过程，仅仅是为了比较。读者可以亲自实验，在BDK的BeanBox中放两个ovalDemo豆，将它们的color属性与ovalNumber属性分别关联起来，并修改发出关联线的豆的这两个属性。可以看到color属性的变化是正常的，即接收关联线的豆的color属性会随着变化，而ovalNumber完全看不出来关联的效果。

　　～～～～

　　还有几个例子，以后再补充。

　　～～～～