java类库中的设计模式（2）

　　Java中的设计模式（一）设计模式简介

　　如果要问起近10年来在计算机软件工程领域所取得的重大成就，那么就不能不提到设计模式（Design Pattern）了。 什么是模式呢？

　　1.3 另一个简单的例子

　　实际上这只是工厂方法的最简单，最明显的应用。还有一些地方也会用到工厂方法，但是并不像上面那个问题所表现的那么直接。再举个最简单的例子吧，比如我们需要一个类来完成两个逻辑变量的或运算，我们都知道，如果第一个逻辑变量是True，那么可以不用任何计算就可以得到最后的结果是True。而如果不是True，则需要进行运算。根据这一点，我们可以用两个类和工厂方法模式来实现这个模型，以达到简化计算的目的。

class ComputeExp {
　　 boolean a,b;
　　 boolean geta(){ return a};
　　 boolean getb(){ return b};
　　 boolean compute(){ return a|b};
　　 public computeExp(boolean a1, boolean b1)
　　 　　 {a=a1;b=b1;};
}
class ComputeExpChild extend ComputeExp{
　　 boolean compute() {return true;};
}
public class ComputeFactory{
　　 ComputeExp createClass(boolean a1, boolean b1){
　　 　　 if (a1==true) return new ComputeExpChild(a1,b1);
　　 else return new ComputeExp(a1,b1);
　　 }
}

　　这段程序应该不再需要什么讲解了吧，简单明了，但是确实揭示了工厂方法模式的一个很重要的应用。需要说明的是，这儿应用的实际上是工厂方法模式的一个变体。可以注意到，我并没有声明一个抽象的超类，而是用其中的一个较为普通的类作为另外一个类的父类。这其实同标准的工厂方法并没有什么不同，毕竟，这些类都有一个公用的接口——这才是工厂方法的精髓所在。

　　当然，这个问题完全没有必要搞的如此复杂，这儿用这个例子，只是想说明工厂方法的另外的应用。也可以说明，并不是所有的问题背景都是明显的，对模式的选择和应用，也需要一定的知识和经验。因而模式并不是万能的，它运用的好坏，还是要取决于施用者对问题的理解程度。

　　上面对设计模式作了一个简要的介绍，相信大家都用该对其有了一些概念了吧。OK，热身完毕，下一篇我们将进入正题，探讨在Java中设计模式的应用。

　　前面说过了，在Java类库中设计模式的踪影随处可见，因而要讲解所有出现的模式实在是不可能，这儿主要把焦点聚集在AWT/Swing中，管中窥豹，却也可以了解设计模式的一些深刻的含义所在。

　　2.1 Composite模式和Component-Container结构

　　Comosite用来将对象组合成树行结构以表示“部分-整体”的层次结构。并且能够将一个组合对象简单化，将其作为单一对象处理。用Composite模式也可以很容易的构造出一个对象树来，并能够方面的进行对象遍历。

　　在Java/AWT中Component-Container是最为明显的一个Composite模式的应用。Component类是所有AWT类的祖先，用来表示一个图形的组件。而Container类是说有容器的的抽象父类，凡是继承了Container的类，都可以在其中容纳其它的Component类或者Container类。我们下面的这个类图中很容易的就可以看到这种关系：

　　在AWT中的Panel，Applet, ScrollPane等等类都是Container类的子类，Windows类也是，但却是一个异数，它，包括它的子类Frame和Dialog是顶级容器，并不能够被其他的容器所包含。我们来看看这样的结构有什么样的作用。

　　首先，可以很容易的对界面中的所有元素进行组织。如果看仔细一点，你会发现上面的那个类图实际上就是一个树。这样组织的结果使得对于组件的处理变得方便。而且通过层层的递归，可以很方便的实现足够复扎的体系。

　　第二，你可以把Container当作一个独立的Component来操作，而不必理会它是否真的是一个Container类。这样说好像有一点饶舌，举个例子你就明白了。在Component中又一个validate()方法来用来显示组件，Container作为Comonent的子类，当然也会有validate()方法，当然它的具体实现是不同于Component的。我们在使用validate()方法时，并不需要理会它是被施用在Container类或者是被施用在Component类上。对于Container而言，当validate()被调用后，它不仅要处理其自生的显示，而且要处理所有其子元素（子节点）的显示，将validate()方法传递下去。但是对于客户而言，所作的只是把容器当作一个组件调用了它的validate()方法，避免了琐碎的细节，简化了客户代码。

　　第三，Container可以代理一些它所包含的子Component的功能。例如，如果客户调用一个组件的getFont()方法，但是在这个组件并没有显式的设定字体值，也就是说当前的Font属性不可用。那么getFont()可以被代理到其高层的容器上，如果这个容器Font属性不是null，就会返回这个Font属性作为哪个子Component的getFont()方法的返回值。

　　我们在反过来看看Composite模式的一些细节，下面给出了Composite的类图：

　　Client考虑的只是Component中所定义的接口。当他进行接口调用的时候，如果是Leaf，那么过程调用简单的进行，但如果是Composite，调用将会被传递给其所有的子Component。这就是Composite模式的关键所在。当然，对于Composite而言，应该有一种数据结构来保存其所有子Component的引用，并提供适当的方法来对这些子Component进行管理。

　　在Java/AWT中的菜单的结构也是Composite模式的一个例子，这儿就不再多讲了。