您的位置: 首页  >  文章  >  设计模式（2）

设计模式（2）

分类: 文章 • 2025-04-18 09:20:58

模板方法


定义：定义一个操作中算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变算法的结构即可重定义该算法中的某些特定步骤。

类型：行为类模式

类图：

设计模式（2）

        事实上，模版方法是编程中一个经常用到的模式。先来看一个例子，某日，程序员A拿到一个任务：给定一个整数数组，把数组中的数由小到大排序，然后把排序之后的结果打印出来。经过分析之后，这个任务大体上可分为两部分，排序和打印，打印功能好实现，排序就有点麻烦了。但是A有办法，先把打印功能完成，排序功能另找人做。

[java] view plain copy
  1. abstract class AbstractSort {  
  2.       
  3.     /** 
  4.      * 将数组array由小到大排序 
  5.      * @param array 
  6.      */  
  7.     protected abstract void sort(int[] array);  
  8.       
  9.     public void showSortResult(int[] array){  
  10.         this.sort(array);  
  11.         System.out.print("排序结果：");  
  12.         for (int i = 0; i < array.length; i++){  
  13.             System.out.printf("%3s", array[i]);  
  14.         }  
  15.     }  
  16. }  

        写完后，A找到刚毕业入职不久的同事B说：有个任务，主要逻辑我已经写好了，你把剩下的逻辑实现一下吧。于是把AbstractSort类给B，让B写实现。B拿过来一看，太简单了，10分钟搞定，代码如下：

[java] view plain copy
  1. class ConcreteSort extends AbstractSort {  
  2.   
  3.     @Override  
  4.     protected void sort(int[] array){  
  5.         for(int i=0; i<array.length-1; i++){  
  6.             selectSort(array, i);  
  7.         }  
  8.     }  
  9.       
  10.     private void selectSort(int[] array, int index) {  
  11.         int MinValue = 32767; // 最小值变量  
  12.         int indexMin = 0; // 最小值索引变量  
  13.         int Temp; // 暂存变量  
  14.         for (int i = index; i < array.length; i++) {  
  15.             if (array[i] < MinValue){ // 找到最小值  
  16.                 MinValue = array[i]; // 储存最小值  
  17.                 indexMin = i;   
  18.             }  
  19.         }  
  20.         Temp = array[index]; // 交换两数值  
  21.         array[index] = array[indexMin];  
  22.         array[indexMin] = Temp;  
  23.     }  
  24. }  

写好后交给A，A拿来一运行：

[java] view plain copy
  1. public class Client {  
  2.     public static int[] a = { 10, 32, 1, 9, 5, 7, 12, 0, 4, 3 }; // 预设数据数组  
  3.     public static void main(String[] args){  
  4.         AbstractSort s = new ConcreteSort();  
  5.         s.showSortResult(a);  
  6.     }  
  7. }  

运行结果：

排序结果：  0  1  3  4  5  7  9 10 12 32

        运行正常。行了，任务完成。没错，这就是模版方法模式。大部分刚步入职场的毕业生应该都有类似B的经历。一个复杂的任务，由公司中的牛人们将主要的逻辑写好，然后把那些看上去比较简单的方法写成抽象的，交给其他的同事去开发。这种分工方式在编程人员水平层次比较明显的公司中经常用到。比如一个项目组，有架构师，高级工程师，初级工程师，则一般由架构师使用大量的接口、抽象类将整个系统的逻辑串起来，实现的编码则根据难度的不同分别交给高级工程师和初级工程师来完成。怎么样，是不是用到过模版方法模式？

 

模版方法模式的结构

       模版方法模式由一个抽象类和一个（或一组）实现类通过继承结构组成，抽象类中的方法分为三种：

  • 抽象方法：父类中只声明但不加以实现，而是定义好规范，然后由它的子类去实现。
  • 模版方法：由抽象类声明并加以实现。一般来说，模版方法调用抽象方法来完成主要的逻辑功能，并且，模版方法大多会定义为final类型，指明主要的逻辑功能在子类中不能被重写。
  • 钩子方法：由抽象类声明并加以实现。但是子类可以去扩展，子类可以通过扩展钩子方法来影响模版方法的逻辑。
  • 抽象类的任务是搭建逻辑的框架，通常由经验丰富的人员编写，因为抽象类的好坏直接决定了程序是否稳定性。

       实现类用来实现细节。抽象类中的模版方法正是通过实现类扩展的方法来完成业务逻辑。只要实现类中的扩展方法通过了单元测试，在模版方法正确的前提下，整体功能一般不会出现大的错误。

 

模版方法的优点及适用场景

       容易扩展。一般来说，抽象类中的模版方法是不易反生改变的部分，而抽象方法是容易反生变化的部分，因此通过增加实现类一般可以很容易实现功能的扩展，符合开闭原则。

       便于维护。对于模版方法模式来说，正是由于他们的主要逻辑相同，才使用了模版方法，假如不使用模版方法，任由这些相同的代码散乱的分布在不同的类中，维护起来是非常不方便的。

       比较灵活。因为有钩子方法，因此，子类的实现也可以影响父类中主逻辑的运行。但是，在灵活的同时，由于子类影响到了父类，违反了里氏替换原则，也会给程序带来风险。这就对抽象类的设计有了更高的要求。

       在多个子类拥有相同的方法，并且这些方法逻辑相同时，可以考虑使用模版方法模式。在程序的主框架相同，细节不同的场合下，也比较适合使用这种模式。


中介者模式

定义：用一个中介者对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使耦合松散，而且可以独立地改变它们之间的交互。

类型：行为类模式

类图：

设计模式（2）

中介者模式的结构

       中介者模式又称为调停者模式，从类图中看，共分为3部分：

  •  抽象中介者：定义好同事类对象到中介者对象的接口，用于各个同事类之间的通信。一般包括一个或几个抽象的事件方法，并由子类去实现。
  • 中介者实现类：从抽象中介者继承而来，实现抽象中介者中定义的事件方法。从一个同事类接收消息，然后通过消息影响其他同时类。
  • 同事类：如果一个对象会影响其他的对象，同时也会被其他对象影响，那么这两个对象称为同事类。在类图中，同事类只有一个，这其实是现实的省略，在实际应用中，同事类一般由多个组成，他们之间相互影响，相互依赖。同事类越多，关系越复杂。并且，同事类也可以表现为继承了同一个抽象类的一组实现组成。在中介者模式中，同事类之间必须通过中介者才能进行消息传递。

为什么要使用中介者模式

       一般来说，同事类之间的关系是比较复杂的，多个同事类之间互相关联时，他们之间的关系会呈现为复杂的网状结构，这是一种过度耦合的架构，即不利于类的复用，也不稳定。例如在下图中，有六个同事类对象，假如对象1发生变化，那么将会有4个对象受到影响。如果对象2发生变化，那么将会有5个对象受到影响。也就是说，同事类之间直接关联的设计是不好的。

设计模式（2）设计模式（2）

        如果引入中介者模式，那么同事类之间的关系将变为星型结构，从图中可以看到，任何一个类的变动，只会影响的类本身，以及中介者，这样就减小了系统的耦合。一个好的设计，必定不会把所有的对象关系处理逻辑封装在本类中，而是使用一个专门的类来管理那些不属于自己的行为。

设计模式（2）

        我们使用一个例子来说明一下什么是同事类：有两个类A和B，类中各有一个数字，并且要保证类B中的数字永远是类A中数字的100倍。也就是说，当修改类A的数时，将这个数字乘以100赋给类B，而修改类B时，要将数除以100赋给类A。类A类B互相影响，就称为同事类。代码如下：

[java] view plain copy
  1. abstract class AbstractColleague {  
  2.     protected int number;  
  3.   
  4.     public int getNumber() {  
  5.         return number;  
  6.     }  
  7.   
  8.     public void setNumber(int number){  
  9.         this.number = number;  
  10.     }  
  11.     //抽象方法，修改数字时同时修改关联对象  
  12.     public abstract void setNumber(int number, AbstractColleague coll);  
  13. }  
  14.   
  15. class ColleagueA extends AbstractColleague{  
  16.     public void setNumber(int number, AbstractColleague coll) {  
  17.         this.number = number;  
  18.         coll.setNumber(number*100);  
  19.     }  
  20. }  
  21.   
  22. class ColleagueB extends AbstractColleague{  
  23.       
  24.     public void setNumber(int number, AbstractColleague coll) {  
  25.         this.number = number;  
  26.         coll.setNumber(number/100);  
  27.     }  
  28. }  
  29.   
  30. public class Client {  
  31.     public static void main(String[] args){  
  32.   
  33.         AbstractColleague collA = new ColleagueA();  
  34.         AbstractColleague collB = new ColleagueB();  
  35.           
  36.         System.out.println("==========设置A影响B==========");  
  37.         collA.setNumber(1288, collB);  
  38.         System.out.println("collA的number值："+collA.getNumber());  
  39.         System.out.println("collB的number值："+collB.getNumber());  
  40.   
  41.         System.out.println("==========设置B影响A==========");  
  42.         collB.setNumber(87635, collA);  
  43.         System.out.println("collB的number值："+collB.getNumber());  
  44.         System.out.println("collA的number值："+collA.getNumber());  
  45.     }  
  46. }  

        上面的代码中，类A类B通过直接的关联发生关系，假如我们要使用中介者模式，类A类B之间则不可以直接关联，他们之间必须要通过一个中介者来达到关联的目的。

[java] view plain copy
  1. abstract class AbstractColleague {  
  2.     protected int number;  
  3.   
  4.     public int getNumber() {  
  5.         return number;  
  6.     }  
  7.   
  8.     public void setNumber(int number){  
  9.         this.number = number;  
  10.     }  
  11.     //注意这里的参数不再是同事类，而是一个中介者  
  12.     public abstract void setNumber(int number, AbstractMediator am);  
  13. }  
  14.   
  15. class ColleagueA extends AbstractColleague{  
  16.   
  17.     public void setNumber(int number, AbstractMediator am) {  
  18.         this.number = number;  
  19.         am.AaffectB();  
  20.     }  
  21. }  
  22.   
  23. class ColleagueB extends AbstractColleague{  
  24.   
  25.     @Override  
  26.     public void setNumber(int number, AbstractMediator am) {  
  27.         this.number = number;  
  28.         am.BaffectA();  
  29.     }  
  30. }  
  31.   
  32. abstract class AbstractMediator {  
  33.     protected AbstractColleague A;  
  34.     protected AbstractColleague B;  
  35.       
  36.     public AbstractMediator(AbstractColleague a, AbstractColleague b) {  
  37.         A = a;  
  38.         B = b;  
  39.     }  
  40.   
  41.     public abstract void AaffectB();  
  42.       
  43.     public abstract void BaffectA();  
  44.   
  45. }  
  46. class Mediator extends AbstractMediator {  
  47.   
  48.     public Mediator(AbstractColleague a, AbstractColleague b) {  
  49.         super(a, b);  
  50.     }  
  51.   
  52.     //处理A对B的影响  
  53.     public void AaffectB() {  
  54.         int number = A.getNumber();  
  55.         B.setNumber(number*100);  
  56.     }  
  57.   
  58.     //处理B对A的影响  
  59.     public void BaffectA() {  
  60.         int number = B.getNumber();  
  61.         A.setNumber(number/100);  
  62.     }  
  63. }  
  64.   
  65. public class Client {  
  66.     public static void main(String[] args){  
  67.         AbstractColleague collA = new ColleagueA();  
  68.         AbstractColleague collB = new ColleagueB();  
  69.           
  70.         AbstractMediator am = new Mediator(collA, collB);  
  71.           
  72.         System.out.println("==========通过设置A影响B==========");  
  73.         collA.setNumber(1000, am);  
  74.         System.out.println("collA的number值为："+collA.getNumber());  
  75.         System.out.println("collB的number值为A的10倍："+collB.getNumber());  
  76.   
  77.         System.out.println("==========通过设置B影响A==========");  
  78.         collB.setNumber(1000, am);  
  79.         System.out.println("collB的number值为："+collB.getNumber());  
  80.         System.out.println("collA的number值为B的0.1倍："+collA.getNumber());  
  81.           
  82.     }  
  83. }  

        虽然代码比较长，但是还是比较容易理解的，其实就是把原来处理对象关系的代码重新封装到一个中介类中，通过这个中介类来处理对象间的关系。

中介者模式的优点

  • 适当地使用中介者模式可以避免同事类之间的过度耦合，使得各同事类之间可以相对独立地使用。
  • 使用中介者模式可以将对象间一对多的关联转变为一对一的关联，使对象间的关系易于理解和维护。
  • 使用中介者模式可以将对象的行为和协作进行抽象，能够比较灵活的处理对象间的相互作用。

适用场景

       在面向对象编程中，一个类必然会与其他的类发生依赖关系，完全独立的类是没有意义的。一个类同时依赖多个类的情况也相当普遍，既然存在这样的情况，说明，一对多的依赖关系有它的合理性，适当的使用中介者模式可以使原本凌乱的对象关系清晰，但是如果滥用，则可能会带来反的效果。一般来说，只有对于那种同事类之间是网状结构的关系，才会考虑使用中介者模式。可以将网状结构变为星状结构，使同事类之间的关系变的清晰一些。

       中介者模式是一种比较常用的模式，也是一种比较容易被滥用的模式。对于大多数的情况，同事类之间的关系不会复杂到混乱不堪的网状结构，因此，大多数情况下，将对象间的依赖关系封装的同事类内部就可以的，没有必要非引入中介者模式。滥用中介者模式，只会让事情变的更复杂。


观察者模式

定义：定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。

类型：行为类模式

类图：

设计模式（2）

        在软件系统中经常会有这样的需求：如果一个对象的状态发生改变，某些与它相关的对象也要随之做出相应的变化。比如，我们要设计一个右键菜单的功能，只要在软件的有效区域内点击鼠标右键，就会弹出一个菜单；再比如，我们要设计一个自动部署的功能，就像eclipse开发时，只要修改了文件，eclipse就会自动将修改的文件部署到服务器中。这两个功能有一个相似的地方，那就是一个对象要时刻监听着另一个对象，只要它的状态一发生改变，自己随之要做出相应的行动。其实，能够实现这一点的方案很多，但是，无疑使用观察者模式是一个主流的选择。

观察者模式的结构

在最基础的观察者模式中，包括以下四个角色：

  • 被观察者：从类图中可以看到，类中有一个用来存放观察者对象的Vector容器（之所以使用Vector而不使用List，是因为多线程操作时，Vector在是安全的，而List则是不安全的），这个Vector容器是被观察者类的核心，另外还有三个方法：attach方法是向这个容器中添加观察者对象；detach方法是从容器中移除观察者对象；notify方法是依次调用观察者对象的对应方法。这个角色可以是接口，也可以是抽象类或者具体的类，因为很多情况下会与其他的模式混用，所以使用抽象类的情况比较多。
  • 观察者：观察者角色一般是一个接口，它只有一个update方法，在被观察者状态发生变化时，这个方法就会被触发调用。
  • 具体的被观察者：使用这个角色是为了便于扩展，可以在此角色中定义具体的业务逻辑。
  • 具体的观察者：观察者接口的具体实现，在这个角色中，将定义被观察者对象状态发生变化时所要处理的逻辑。

观察者模式代码实现

[java] view plain copy
  1. abstract class Subject {  
  2.     private Vector<Observer> obs = new Vector<Observer>();  
  3.       
  4.     public void addObserver(Observer obs){  
  5.         this.obs.add(obs);  
  6.     }  
  7.     public void delObserver(Observer obs){  
  8.         this.obs.remove(obs);  
  9.     }  
  10.     protected void notifyObserver(){  
  11.         for(Observer o: obs){  
  12.             o.update();  
  13.         }  
  14.     }  
  15.     public abstract void doSomething();  
  16. }  
  17.   
  18. class ConcreteSubject extends Subject {  
  19.     public void doSomething(){  
  20.         System.out.println("被观察者事件反生");  
  21.         this.notifyObserver();  
  22.     }  
  23. }  
  24. interface Observer {  
  25.     public void update();  
  26. }  
  27. class ConcreteObserver1 implements Observer {  
  28.     public void update() {  
  29.         System.out.println("观察者1收到信息，并进行处理。");  
  30.     }  
  31. }  
  32. class ConcreteObserver2 implements Observer {  
  33.     public void update() {  
  34.         System.out.println("观察者2收到信息，并进行处理。");  
  35.     }  
  36. }  
  37.   
  38. public class Client {  
  39.     public static void main(String[] args){  
  40.         Subject sub = new ConcreteSubject();  
  41.         sub.addObserver(new ConcreteObserver1()); //添加观察者1  
  42.         sub.addObserver(new ConcreteObserver2()); //添加观察者2  
  43.         sub.doSomething();  
  44.     }  
  45. }  


运行结果

被观察者事件反生

观察者1收到信息，并进行处理。

观察者2收到信息，并进行处理。

        通过运行结果可以看到，我们只调用了Subject的方法，但同时两个观察者的相关方法都被同时调用了。仔细看一下代码，其实很简单，无非就是在Subject类中关联一下Observer类，并且在doSomething方法中遍历一下Observer的update方法就行了。

观察者模式的优点

        观察者与被观察者之间是属于轻度的关联关系，并且是抽象耦合的，这样，对于两者来说都比较容易进行扩展。

        观察者模式是一种常用的触发机制，它形成一条触发链，依次对各个观察者的方法进行处理。但同时，这也算是观察者模式一个缺点，由于是链式触发，当观察者比较多的时候，性能问题是比较令人担忧的。并且，在链式结构中，比较容易出现循环引用的错误，造成系统假死。

 

总结

       java语言中，有一个接口Observer，以及它的实现类Observable，对观察者角色常进行了实现。我们可以在jdk的api文档具体查看这两个类的使用方法。

       做过VC++、javascript DOM或者AWT开发的朋友都对它们的事件处理感到神奇，了解了观察者模式，就对事件处理机制的原理有了一定的了解了。如果要设计一个事件触发处理机制的功能，使用观察者模式是一个不错的选择，AWT中的事件处理DEM（委派事件模型Delegation Event Model）就是使用观察者模式实现的。

笔记：观察者模式多用于页面，可以根据客户点击显示不同内容，可以根据客户操作更新内容等等。



访问者模式


先了解java的动态绑定

        所谓的动态绑定就是指程执行期间（而不是在编译期间）判断所引用对象的实际类型，根据其实际的类型调用其相应的方法。java继承体系中的覆盖就是动态绑定的，看一下如下的代码：

[java] view plain copy
  1. class Father {  
  2.     public void method(){  
  3.         System.out.println("This is Father's method");  
  4.     }  
  5. }  
  6.   
  7. class Son1 extends Father{  
  8.     public void method(){  
  9.         System.out.println("This is Son1's method");  
  10.     }  
  11. }  
  12.   
  13. class Son2 extends Father{  
  14.     public void method(){  
  15.         System.out.println("This is Son2's method");  
  16.     }  
  17. }  
  18.   
  19. public class Test {  
  20.     public static void main(String[] args){  
  21.         Father s1 = new Son1();  
  22.         s1.method();  
  23.           
  24.         Father s2 = new Son2();  
  25.         s2.method();  
  26.     }  
  27. }  


运行结果如下：

This is Son1's method
This is Son2's method

       通过运行结果可以看到，尽管我们引用的类型是Father类型的，但是运行时却是调用的它实际类型（也就是Son1和Son2）的方法，这就是动态绑定。在java语言中，继承中的覆盖就是是动态绑定的，当我们用父类引用实例化子类时，会根据引用的实际类型调用相应的方法。

 

java的静态绑定

       相对于动态绑定，静态绑定就是指在编译期就已经确定执行哪一个方法。在java中，方法的重载（方法名相同而参数不同）就是静态绑定的，重载时，执行哪一个方法在编译期就已经确定下来了。看一下代码：

[java] view plain copy
  1. class Father {}  
  2. class Son1 extends Father{}  
  3. class Son2 extends Father{}  
  4.   
  5. class Execute {  
  6.     public void method(Father father){  
  7.         System.out.println("This is Father's method");  
  8.     }  
  9.       
  10.     public void method(Son1 son){  
  11.         System.out.println("This is Son1's method");  
  12.     }  
  13.       
  14.     public void method(Son2 son){  
  15.         System.out.println("This is Son2's method");  
  16.     }  
  17. }  
  18.   
  19. public class Test {  
  20.     public static void main(String[] args){  
  21.         Father father = new Father();  
  22.         Father s1 = new Son1();  
  23.         Father s2 = new Son2();  
  24.   
  25.         Execute exe = new Execute();  
  26.         exe.method(father);  
  27.         exe.method(s1);  
  28.         exe.method(s2);  
  29.     }  
  30. }  


运行结果如下：

This is Father's method
This is Father's method
This is Father's method

        在这里，程序在编译的时候就已经确定使用method(Father father)方法了，不管我们在运行的时候传入的实际类型是什么，它永远都只会执行method(Father father)这个方法。也就是说，java的重载是静态绑定的。

 

instanceof操作符与转型

       有时候，我们希望在使用重载的时候，程序能够根据传入参数的实际类型动态地调用相应的方法，也就是说，我们希望java的重载是动态的，而不是静态的。但是由于java的重载不是动态绑定，我们只能通过程序来人为的判断，我们一般会使用instanceof操作符来进行类型的判断。我们要对method(Father father)进行修改，在方法体中判断运行期间的实际类型，修改后的method(Father father)方法如下：

[java] view plain copy
  1. public void method(Father father){  
  2.     if(father instanceof Son1){  
  3.         method((Son1)father);  
  4.     }else if(father instanceof Son2){  
  5.         method((Son2)father);  
  6.     }else if(father instanceof Father){  
  7.         System.out.println("This is Father's method");  
  8.     }  
  9. }  

java 中的instanceof 运算符是用来在运行时指出对象是否是特定类的一个实例。instanceof通过返回一个布尔值来指出，这个对象是否是这个特定类或者是它的子类的一个实例。       


请注意，我们必须把判断是否是父类的条件（也就是判断是否为Father类的条件）放到最后，否则将一律会被判断为Father类，达不到我们动态判断的目的。修改代码后，程序就可以动态地根据参数的实际类型来调用相应的方法了。运行结果如下：

This is Father's method
This is Son1's method
This is Son2's method

        但是这种实现方式有一个明显的缺点，它是伪动态的，仍然需要我们来通过程序来判断类型。假如Father有100个子类的话，还是这样来实现显然是不合适的。必须通过其他更好的方式实现才行，我们可以使用双分派方式来实现动态绑定。

      

用双分派实现动态绑定

        首先，什么是双分派？还记得23种设计模式（9）：访问者模式中一开始举的例子吗？

        类A中的方法method1和method2的区别就是，method2是双分派。我们可以看一下java双分派的特点：首先要有一个访问类B，类B提供一个showA(A a) 方法，在方法中，调用类A的method1方法，然后类A的method2方法中调用类B的showA方法并将自己作为参数传给showA。双分派的核心就是这个this对象。说到这里，我们已经明白双分派是怎么回事了，但是它有什么效果呢？就是可以实现方法的动态绑定，我们可以对上面的程序进行修改，代码如下：

[java] view plain copy
  1. class Father {  
  2.     public void accept(Execute exe){  
  3.         exe.method(this);  
  4.     }  
  5. }  
  6. class Son1 extends Father{  
  7.     public void accept(Execute exe){  
  8.         exe.method(this);  
  9.     }  
  10. }  
  11. class Son2 extends Father{  
  12.     public void accept(Execute exe){  
  13.         exe.method(this);  
  14.     }  
  15. }  
  16.   
  17. class Execute {  
  18.     public void method(Father father){  
  19.         System.out.println("This is Father's method");  
  20.     }  
  21.       
  22.     public void method(Son1 son){  
  23.         System.out.println("This is Son1's method");  
  24.     }  
  25.       
  26.     public void method(Son2 son){  
  27.         System.out.println("This is Son2's method");  
  28.     }  
  29. }  
  30.   
  31. public class Test {  
  32.     public static void main(String[] args){  
  33.         Father father = new Father();  
  34.         Father s1 = new Son1();  
  35.         Father s2 = new Son2();  
  36.   
  37.         Execute exe = new Execute();  
  38.         father.accept(exe);  
  39.         s1.accept(exe);  
  40.         s2.accept(exe);  
  41.     }  
  42. }  

        可以看到我们修改的地方，在Father，Son1，Son2中分别加入一个双分派的方法。调用的时候，原本是调用Execute的method方法，现在改为调用Father的accept方法。运行结果如下：

This is Father's method
This is Son1's method
This is Son2's method

        运行结果符合我们的预期，实现了动态绑定。双分派实现动态绑定的本质，就是在重载方法委派的前面加上了继承体系中覆盖的环节，由于覆盖是动态的，所以重载就是动态的了，与使用instanceof操作符的效果是一样的（用instanceof操作符可以实现重载方法动态绑定的原因也是因为instanceof操作符是动态的）。但是与使用instanceof操作符实现动态绑定相比，双分派方式的可扩展性要好的多。


定义：封装某些作用于某种数据结构中各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

类型：行为类模式

类图：

设计模式（2）

       访问者模式可能是行为类模式中最复杂的一种模式了，但是这不能成为我们不去掌握它的理由。我们首先来看一个简单的例子，代码如下：

[java] view plain copy
  1. class A {  
  2.     public void method1(){  
  3.         System.out.println("我是A");  
  4.     }  
  5.       
  6.     public void method2(B b){  
  7.         b.showA(this);  
  8.     }  
  9. }  
  10.   
  11. class B {  
  12.     public void showA(A a){  
  13.         a.method1();  
  14.     }  
  15. }  

        我们主要来看一下在类A中，方法method1和方法method2的区别在哪里，方法method1很简单，就是打印出一句“我是A”；方法method2稍微复杂一点，使用类B作为参数，并调用类B的showA方法。再来看一下类B的showA方法，showA方法使用类A作为参数，然后调用类A的method1方法，可以看到，method2方法绕来绕去，无非就是调用了一下自己的method1方法而已，它的运行结果应该也是“我是A”，分析完之后，我们来运行一下这两个方法，并看一下运行结果：

[java] view plain copy
  1. public class Test {  
  2.     public static void main(String[] args){  
  3.         A a = new A();  
  4.         a.method1();  
  5.         a.method2(new B());  
  6.     }  
  7. }  

运行结果为：

我是A
我是A

       看懂了这个例子，就理解了访问者模式的90%，在例子中，对于类A来说，类B就是一个访问者。但是这个例子并不是访问者模式的全部，虽然直观，但是它的可扩展性比较差，下面我们就来说一下访问者模式的通用实现，通过类图可以看到，在访问者模式中，主要包括下面几个角色：

  •  抽象访问者：抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是visit方法中的参数定义哪些对象是可以被访问的。
  • 访问者：实现抽象访问者所声明的方法，它影响到访问者访问到一个类后该干什么，要做什么事情。
  • 抽象元素类：接口或者抽象类，声明接受哪一类访问者访问，程序上是通过accept方法中的参数来定义的。抽象元素一般有两类方法，一部分是本身的业务逻辑，另外就是允许接收哪类访问者来访问。
  • 元素类：实现抽象元素类所声明的accept方法，通常都是visitor.visit(this)，基本上已经形成一种定式了。
  • 结构对象：一个元素的容器，一般包含一个容纳多个不同类、不同接口的容器，如List、Set、Map等，在项目中一般很少抽象出这个角色。

 访问者模式的通用代码实现

[java] view plain copy
  1. abstract class Element {  
  2.     public abstract void accept(IVisitor visitor);  
  3.     public abstract void doSomething();  
  4. }  
  5.   
  6. interface IVisitor {  
  7.     public void visit(ConcreteElement1 el1);  
  8.     public void visit(ConcreteElement2 el2);  
  9. }  
  10.   
  11. class ConcreteElement1 extends Element {  
  12.     public void doSomething(){  
  13.         System.out.println("这是元素1");  
  14.     }  
  15.       
  16.     public void accept(IVisitor visitor) {  
  17.         visitor.visit(this);  
  18.     }  
  19. }  
  20.   
  21. class ConcreteElement2 extends Element {  
  22.     public void doSomething(){  
  23.         System.out.println("这是元素2");  
  24.     }  
  25.       
  26.     public void accept(IVisitor visitor) {  
  27.         visitor.visit(this);  
  28.     }  
  29. }  
  30. class Visitor implements IVisitor {  
  31.   
  32.     public void visit(ConcreteElement1 el1) {  
  33.         el1.doSomething();  
  34.     }  
  35.       
  36.     public void visit(ConcreteElement2 el2) {  
  37.         el2.doSomething();  
  38.     }  
  39. }  
  40.   
  41. class ObjectStruture {  
  42.     public static List<Element> getList(){  
  43.         List<Element> list = new ArrayList<Element>();  
  44.         Random ran = new Random();  
  45.         for(int i=0; i<10; i++){  
  46.             int a = ran.nextInt(100);  
  47.             if(a>50){  
  48.                 list.add(new ConcreteElement1());  
  49.             }else{  
  50.                 list.add(new ConcreteElement2());  
  51.             }  
  52.         }  
  53.         return list;  
  54.     }  
  55. }  
  56.   
  57. public class Client {  
  58.     public static void main(String[] args){  
  59.         List<Element> list = ObjectStruture.getList();  
  60.         for(Element e: list){  
  61.             e.accept(new Visitor());  
  62.         }  
  63.     }  
  64. }  


访问者模式的优点

  • 符合单一职责原则：凡是适用访问者模式的场景中，元素类中需要封装在访问者中的操作必定是与元素类本身关系不大且是易变的操作，使用访问者模式一方面符合单一职责原则，另一方面，因为被封装的操作通常来说都是易变的，所以当发生变化时，就可以在不改变元素类本身的前提下，实现对变化部分的扩展。
  • 扩展性良好：元素类可以通过接受不同的访问者来实现对不同操作的扩展。

 访问者模式的适用场景

       假如一个对象中存在着一些与本对象不相干（或者关系较弱）的操作，为了避免这些操作污染这个对象，则可以使用访问者模式来把这些操作封装到访问者中去。

       假如一组对象中，存在着相似的操作，为了避免出现大量重复的代码，也可以将这些重复的操作封装到访问者中去。

       但是，访问者模式并不是那么完美，它也有着致命的缺陷：增加新的元素类比较困难。通过访问者模式的代码可以看到，在访问者类中，每一个元素类都有它对应的处理方法，也就是说，每增加一个元素类都需要修改访问者类（也包括访问者类的子类或者实现类），修改起来相当麻烦。也就是说，在元素类数目不确定的情况下，应该慎用访问者模式。所以，访问者模式比较适用于对已有功能的重构，比如说，一个项目的基本功能已经确定下来，元素类的数据已经基本确定下来不会变了，会变的只是这些元素内的相关操作，这时候，我们可以使用访问者模式对原有的代码进行重构一遍，这样一来，就可以在不修改各个元素类的情况下，对原有功能进行修改。


笔记：访问者就像一个有多个功能的处理中心，每一个重载方法都有一个特定的功能，而这些功能都需要元素中某些方法。

这样可以在不改变元素方法条件下使用它，减少了代码重复也避免污染对象。


命令模式

定义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

类型：行为类模式

类图：

设计模式（2）

命令模式的结构

        顾名思义，命令模式就是对命令的封装，首先来看一下命令模式类图中的基本结构：

  • Command类：是一个抽象类，类中对需要执行的命令进行声明，一般来说要对外公布一个execute方法用来执行命令。
  • ConcreteCommand类：Command类的实现类，对抽象类中声明的方法进行实现。
  • Client类：最终的客户端调用类。

        以上三个类的作用应该是比较好理解的，下面我们重点说一下Invoker类和Recevier类。

  • Invoker类：调用者，负责调用命令。
  • Receiver类：接收者，负责接收命令并且执行命令。

        所谓对命令的封装，说白了，无非就是把一系列的操作写到一个方法中，然后供客户端调用就行了，反映到类图上，只需要一个ConcreteCommand类和Client类就可以完成对命令的封装，即使再进一步，为了增加灵活性，可以再增加一个Command类进行适当地抽象，这个调用者和接收者到底是什么作用呢？

        其实大家可以换一个角度去想：假如仅仅是简单地把一些操作封装起来作为一条命令供别人调用，怎么能称为一种模式呢？命令模式作为一种行为类模式，首先要做到低耦合，耦合度低了才能提高灵活性，而加入调用者和接收者两个角色的目的也正是为此。命令模式的通用代码如下：

[java] view plain copy
  1. class Invoker {  
  2.     private Command command;  
  3.     public void setCommand(Command command) {  
  4.         this.command = command;  
  5.     }  
  6.     public void action(){  
  7.         this.command.execute();  
  8.     }  
  9. }  
  10.   
  11. abstract class Command {  
  12.     public abstract void execute();  
  13. }  
  14.   
  15. class ConcreteCommand extends Command {  
  16.     private Receiver receiver;  
  17.     public ConcreteCommand(Receiver receiver){  
  18.         this.receiver = receiver;  
  19.     }  
  20.     public void execute() {  
  21.         this.receiver.doSomething();  
  22.     }  
  23. }  
  24.   
  25. class Receiver {  
  26.     public void doSomething(){  
  27.         System.out.println("接受者-业务逻辑处理");  
  28.     }  
  29. }  
  30.   
  31. public class Client {  
  32.     public static void main(String[] args){  
  33.         Receiver receiver = new Receiver();  
  34.         Command command = new ConcreteCommand(receiver);  
  35.         //客户端直接执行具体命令方式（此方式与类图相符）  
  36.         command.execute();  
  37.   
  38.         //客户端通过调用者来执行命令  
  39.         Invoker invoker = new Invoker();  
  40.         invoker.setCommand(command);  
  41.         invoker.action();  
  42.     }  
  43. }  

        通过代码我们可以看到，当我们调用时，执行的时序首先是调用者类，然后是命令类，最后是接收者类。也就是说一条命令的执行被分成了三步，它的耦合度要比把所有的操作都封装到一个类中要低的多，而这也正是命令模式的精髓所在：把命令的调用者与执行者分开，使双方不必关心对方是如何操作的。

 

命令模式的优缺点

        首先，命令模式的封装性很好：每个命令都被封装起来，对于客户端来说，需要什么功能就去调用相应的命令，而无需知道命令具体是怎么执行的。比如有一组文件操作的命令：新建文件、复制文件、删除文件。如果把这三个操作都封装成一个命令类，客户端只需要知道有这三个命令类即可，至于命令类中封装好的逻辑，客户端则无需知道。

        其次，命令模式的扩展性很好，在命令模式中，在接收者类中一般会对操作进行最基本的封装，命令类则通过对这些基本的操作进行二次封装，当增加新命令的时候，对命令类的编写一般不是从零开始的，有大量的接收者类可供调用，也有大量的命令类可供调用，代码的复用性很好。比如，文件的操作中，我们需要增加一个剪切文件的命令，则只需要把复制文件和删除文件这两个命令组合一下就行了，非常方便。

        最后说一下命令模式的缺点，那就是命令如果很多，开发起来就要头疼了。特别是很多简单的命令，实现起来就几行代码的事，而使用命令模式的话，不用管命令多简单，都需要写一个命令类来封装。

 

命令模式的适用场景

       对于大多数请求-响应模式的功能，比较适合使用命令模式，正如命令模式定义说的那样，命令模式对实现记录日志、撤销操作等功能比较方便。

 

 总结

       对于一个场合到底用不用模式，这对所有的开发人员来说都是一个很纠结的问题。有时候，因为预见到需求上会发生的某些变化，为了系统的灵活性和可扩展性而使用了某种设计模式，但这个预见的需求偏偏没有，相反，没预见到的需求倒是来了不少，导致在修改代码的时候，使用的设计模式反而起了相反的作用，以至于整个项目组怨声载道。这样的例子，我相信每个程序设计者都遇到过。所以，基于敏捷开发的原则，我们在设计程序的时候，如果按照目前的需求，不使用某种模式也能很好地解决，那么我们就不要引入它，因为要引入一种设计模式并不困难，我们大可以在真正需要用到的时候再对系统进行一下，引入这个设计模式。

       拿命令模式来说吧，我们开发中，请求-响应模式的功能非常常见，一般来说，我们会把对请求的响应操作封装到一个方法中，这个封装的方法可以称之为命令，但不是命令模式。到底要不要把这种设计上升到模式的高度就要另行考虑了，因为，如果使用命令模式，就要引入调用者、接收者两个角色，原本放在一处的逻辑分散到了三个类中，设计时，必须考虑这样的代价是否值得。


定义：定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。

类型：行为类模式

类图：

设计模式（2）

        在软件系统中经常会有这样的需求：如果一个对象的状态发生改变，某些与它相关的对象也要随之做出相应的变化。比如，我们要设计一个右键菜单的功能，只要在软件的有效区域内点击鼠标右键，就会弹出一个菜单；再比如，我们要设计一个自动部署的功能，就像eclipse开发时，只要修改了文件，eclipse就会自动将修改的文件部署到服务器中。这两个功能有一个相似的地方，那就是一个对象要时刻监听着另一个对象，只要它的状态一发生改变，自己随之要做出相应的行动。其实，能够实现这一点的方案很多，但是，无疑使用观察者模式是一个主流的选择。

观察者模式的结构

在最基础的观察者模式中，包括以下四个角色：

  • 被观察者：从类图中可以看到，类中有一个用来存放观察者对象的Vector容器（之所以使用Vector而不使用List，是因为多线程操作时，Vector在是安全的，而List则是不安全的），这个Vector容器是被观察者类的核心，另外还有三个方法：attach方法是向这个容器中添加观察者对象；detach方法是从容器中移除观察者对象；notify方法是依次调用观察者对象的对应方法。这个角色可以是接口，也可以是抽象类或者具体的类，因为很多情况下会与其他的模式混用，所以使用抽象类的情况比较多。
  • 观察者：观察者角色一般是一个接口，它只有一个update方法，在被观察者状态发生变化时，这个方法就会被触发调用。
  • 具体的被观察者：使用这个角色是为了便于扩展，可以在此角色中定义具体的业务逻辑。
  • 具体的观察者：观察者接口的具体实现，在这个角色中，将定义被观察者对象状态发生变化时所要处理的逻辑。

观察者模式代码实现

[java] view plain copy
  1. abstract class Subject {  
  2.     private Vector<Observer> obs = new Vector<Observer>();  
  3.       
  4.     public void addObserver(Observer obs){  
  5.         this.obs.add(obs);  
  6.     }  
  7.     public void delObserver(Observer obs){  
  8.         this.obs.remove(obs);  
  9.     }  
  10.     protected void notifyObserver(){  
  11.         for(Observer o: obs){  
  12.             o.update();  
  13.         }  
  14.     }  
  15.     public abstract void doSomething();  
  16. }  
  17.   
  18. class ConcreteSubject extends Subject {  
  19.     public void doSomething(){  
  20.         System.out.println("被观察者事件反生");  
  21.         this.notifyObserver();  
  22.     }  
  23. }  
  24. interface Observer {  
  25.     public void update();  
  26. }  
  27. class ConcreteObserver1 implements Observer {  
  28.     public void update() {  
  29.         System.out.println("观察者1收到信息，并进行处理。");  
  30.     }  
  31. }  
  32. class ConcreteObserver2 implements Observer {  
  33.     public void update() {  
  34.         System.out.println("观察者2收到信息，并进行处理。");  
  35.     }  
  36. }  
  37.   
  38. public class Client {  
  39.     public static void main(String[] args){  
  40.         Subject sub = new ConcreteSubject();  
  41.         sub.addObserver(new ConcreteObserver1()); //添加观察者1  
  42.         sub.addObserver(new ConcreteObserver2()); //添加观察者2  
  43.         sub.doSomething();  
  44.     }  
  45. }  


运行结果

被观察者事件反生

观察者1收到信息，并进行处理。

观察者2收到信息，并进行处理。

        通过运行结果可以看到，我们只调用了Subject的方法，但同时两个观察者的相关方法都被同时调用了。仔细看一下代码，其实很简单，无非就是在Subject类中关联一下Observer类，并且在doSomething方法中遍历一下Observer的update方法就行了。

观察者模式的优点

        观察者与被观察者之间是属于轻度的关联关系，并且是抽象耦合的，这样，对于两者来说都比较容易进行扩展。

        观察者模式是一种常用的触发机制，它形成一条触发链，依次对各个观察者的方法进行处理。但同时，这也算是观察者模式一个缺点，由于是链式触发，当观察者比较多的时候，性能问题是比较令人担忧的。并且，在链式结构中，比较容易出现循环引用的错误，造成系统假死。

 

总结

       java语言中，有一个接口Observer，以及它的实现类Observable，对观察者角色常进行了实现。我们可以在jdk的api文档具体查看这两个类的使用方法。

       做过VC++、javascript DOM或者AWT开发的朋友都对它们的事件处理感到神奇，了解了观察者模式，就对事件处理机制的原理有了一定的了解了。如果要设计一个事件触发处理机制的功能，使用观察者模式是一个不错的选择，AWT中的事件处理DEM（委派事件模型Delegation Event Model）就是使用观察者模式实现的。

定义：将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。

类型：行为类模式

类图：

设计模式（2）

命令模式的结构

        顾名思义，命令模式就是对命令的封装，首先来看一下命令模式类图中的基本结构：

  • Command类：是一个抽象类，类中对需要执行的命令进行声明，一般来说要对外公布一个execute方法用来执行命令。
  • ConcreteCommand类：Command类的实现类，对抽象类中声明的方法进行实现。
  • Client类：最终的客户端调用类。

        以上三个类的作用应该是比较好理解的，下面我们重点说一下Invoker类和Recevier类。

  • Invoker类：调用者，负责调用命令。
  • Receiver类：接收者，负责接收命令并且执行命令。

        所谓对命令的封装，说白了，无非就是把一系列的操作写到一个方法中，然后供客户端调用就行了，反映到类图上，只需要一个ConcreteCommand类和Client类就可以完成对命令的封装，即使再进一步，为了增加灵活性，可以再增加一个Command类进行适当地抽象，这个调用者和接收者到底是什么作用呢？

        其实大家可以换一个角度去想：假如仅仅是简单地把一些操作封装起来作为一条命令供别人调用，怎么能称为一种模式呢？命令模式作为一种行为类模式，首先要做到低耦合，耦合度低了才能提高灵活性，而加入调用者和接收者两个角色的目的也正是为此。命令模式的通用代码如下：

[java] view plain copy
  1. class Invoker {  
  2.     private Command command;  
  3.     public void setCommand(Command command) {  
  4.         this.command = command;  
  5.     }  
  6.     public void action(){  
  7.         this.command.execute();  
  8.     }  
  9. }  
  10.   
  11. abstract class Command {  
  12.     public abstract void execute();  
  13. }  
  14.   
  15. class ConcreteCommand extends Command {  
  16.     private Receiver receiver;  
  17.     public ConcreteCommand(Receiver receiver){  
  18.         this.receiver = receiver;  
  19.     }  
  20.     public void execute() {  
  21.         this.receiver.doSomething();  
  22.     }  
  23. }  
  24.   
  25. class Receiver {  
  26.     public void doSomething(){  
  27.         System.out.println("接受者-业务逻辑处理");  
  28.     }  
  29. }  
  30.   
  31. public class Client {  
  32.     public static void main(String[] args){  
  33.         Receiver receiver = new Receiver();  
  34.         Command command = new ConcreteCommand(receiver);  
  35.         //客户端直接执行具体命令方式（此方式与类图相符）  
  36.         command.execute();  
  37.   
  38.         //客户端通过调用者来执行命令  
  39.         Invoker invoker = new Invoker();  
  40.         invoker.setCommand(command);  
  41.         invoker.action();  
  42.     }  
  43. }  

        通过代码我们可以看到，当我们调用时，执行的时序首先是调用者类，然后是命令类，最后是接收者类。也就是说一条命令的执行被分成了三步，它的耦合度要比把所有的操作都封装到一个类中要低的多，而这也正是命令模式的精髓所在：把命令的调用者与执行者分开，使双方不必关心对方是如何操作的。

 

命令模式的优缺点

        首先，命令模式的封装性很好：每个命令都被封装起来，对于客户端来说，需要什么功能就去调用相应的命令，而无需知道命令具体是怎么执行的。比如有一组文件操作的命令：新建文件、复制文件、删除文件。如果把这三个操作都封装成一个命令类，客户端只需要知道有这三个命令类即可，至于命令类中封装好的逻辑，客户端则无需知道。

        其次，命令模式的扩展性很好，在命令模式中，在接收者类中一般会对操作进行最基本的封装，命令类则通过对这些基本的操作进行二次封装，当增加新命令的时候，对命令类的编写一般不是从零开始的，有大量的接收者类可供调用，也有大量的命令类可供调用，代码的复用性很好。比如，文件的操作中，我们需要增加一个剪切文件的命令，则只需要把复制文件和删除文件这两个命令组合一下就行了，非常方便。

        最后说一下命令模式的缺点，那就是命令如果很多，开发起来就要头疼了。特别是很多简单的命令，实现起来就几行代码的事，而使用命令模式的话，不用管命令多简单，都需要写一个命令类来封装。

 

命令模式的适用场景

       对于大多数请求-响应模式的功能，比较适合使用命令模式，正如命令模式定义说的那样，命令模式对实现记录日志、撤销操作等功能比较方便。

 

 总结

       对于一个场合到底用不用模式，这对所有的开发人员来说都是一个很纠结的问题。有时候，因为预见到需求上会发生的某些变化，为了系统的灵活性和可扩展性而使用了某种设计模式，但这个预见的需求偏偏没有，相反，没预见到的需求倒是来了不少，导致在修改代码的时候，使用的设计模式反而起了相反的作用，以至于整个项目组怨声载道。这样的例子，我相信每个程序设计者都遇到过。所以，基于敏捷开发的原则，我们在设计程序的时候，如果按照目前的需求，不使用某种模式也能很好地解决，那么我们就不要引入它，因为要引入一种设计模式并不困难，我们大可以在真正需要用到的时候再对系统进行一下，引入这个设计模式。

       拿命令模式来说吧，我们开发中，请求-响应模式的功能非常常见，一般来说，我们会把对请求的响应操作封装到一个方法中，这个封装的方法可以称之为命令，但不是命令模式。到底要不要把这种设计上升到模式的高度就要另行考虑了，因为，如果使用命令模式，就要引入调用者、接收者两个角色，原本放在一处的逻辑分散到了三个类中，设计时，必须考虑这样的代价是否值得。

相关推荐