清风

Runtime.getRuntime().exec("cmd /c del c:\\a.doc");

   //Runtime.getRuntime().exec("notepad");

  //Runtime.getRuntime().exec("cmd /c start c:\\a.doc");

  //Runtime.getRuntime().exec("cmd /c start http://www.baidu.com");

   Runtime.getRuntime().exec("cmd /k start c:\\test.bat");   //java调用bat文件
  mysqldump --user=root --host=localhost --password=pass  zhangwei &..

  先简单介绍一下状态模式：将与状态有关处理逻辑分散到代表对象状态各个类中！ 
状态之间的改变都对应一个动作，一个动作可能对应多个状态的改变（动作来描述。可能不是特别准确），如提交，审核.... 

state模式的两个原则： 
1.有几个动作就有几个方法，一个动作可能对应多个状态转换，这些方法都定义在同一个接口里。 
2.有几个状态就有几个实现上述接口的类。 

用户升级vip例子：首先用户必须是注册用户，普通用户升级vip需要提交真实的个人信息，工作人员根据提交信息的真实性进行审核。..

 GoF对访问者模式定义为:表示一个作用于某对象结构中各元素的操作。它可以使你不修改各元素类的前提下定义作用于这些元素的新操作，也就是动态的增加新的方法。
Visitor模式是一种分离对象数据结构与行为的方法，通过这种分离，可以为一个已存在的类或类群增加新的操作而无需为它们作任何修改。

Visitor模式的优点：

- 分离对象的数据结构与行为，让不同的类完成不同的功能

- 可以不修改已有类的基础上增加新的操作行为

- 从另一个角度来看，同一个数据结构，为其实现不同的观察者，便可呈现不同的行为
该模式结构如下..

 中介者模式（Mediator）：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
 
通用类图：
 
举例：在一个公司里面，有很多部门、员工（我们统称他们互相为Colleague“同事”），为了完成一定的任务，“同事”之间肯定有许多需要互相配合、交流的过程。如果由各个“同事”频繁地到处去与自己有关的“同事”沟通，这样肯定会形成一个多对多的杂乱的联系网络而造成工作效率低下。
 
此时就需要一位专门的“中介者”给各个“同事”分配任务，以及统一跟进大家的进度并在“同事”之间实时地进行交互，保证“同事”之间必须的沟通交流。很明显我们知道此时的“中介者”担任了沟通“同事”彼此之间的重要角色了，“中介者”使得每个“同事”都变成一对一的联系方式，减轻了每个“同事”的负担，增强工作效率。
 
大概理清上面简单例子中的意图之后，给出中介者模式适用场景：
1、一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。
2、一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。
3、想定制一个分布在多个类中的行为，而又不想生成太多的子类。
 
其实，中介者模式又被称为“调停者”模式，我们可以理解为一群小孩子（同事）吵架了，这时就很需要一位大人（调停者）过来处理好小孩子们的关系，以免发生不必要的冲突。“中介者”和“调停者”只不过是同一个英语单词“Mediator”的不同翻译罢了。反正最最重要的是：中介者就是一个处于众多对象，并恰当地处理众多对象之间相互之间的联系的角色。
 
下面给出具体的代码例子，对比通用类图增加了AbstractColleague抽象同事类和AbstractMediator抽象中介者，另外就是两个具体同事类和一个具体中介者，代码中有较多注释，相应类图也不给出了，应该不难理解的：
 
         同事类族：
//抽象同事类  abstract class AbstractColleague {      protected AbstractMediator mediator;            /**既然有中介者，那么每个具体同事必然要与中介者有联系，       * 否则就没必要存在于 这个系统当中，这里的构造函数相当       * 于向该系统中注册一个中介者，以取得联系       */     public AbstractColleague(AbstractMediator mediator) {          this.mediator = mediator;      }            // 在抽象同事类中添加用于与中介者取得联系（即注册）的方法      public void setMediator(AbstractMediator mediator) {          this.mediator = mediator;      }  }   //具体同事A  class ColleagueA extends AbstractColleague {            //每个具体同事都通过父类构造函数与中介者取得联系      public ColleagueA(AbstractMediator mediator) {          super(mediator);      }            //每个具体同事必然有自己分内的事，没必要与外界相关联      public void self() {          System.out.println("同事A --> 做好自己分内的事情 ...");      }            //每个具体同事总有需要与外界交互的操作，通过中介者来处理这些逻辑并安排工作      public void out() {          System.out.println("同事A --> 请求同事B做好分内工作 ...");          super.mediator.execute("ColleagueB", "self");      }  }   //具体同事B  class ColleagueB extends AbstractColleague {            public ColleagueB(AbstractMediator mediator) {          super(mediator);      }            public void self() {          System.out.println("同事B --> 做好自己分内的事情 ...");      }            public void out() {          System.out.println("同事B --> 请求同事A做好分内工作  ...");          super.mediator.execute("ColleagueA", "self");      }  } 
中介者类族：
//抽象中介者  abstract class AbstractMediator {            //中介者肯定需要保持有若干同事的联系方式      protected Hashtable<String, AbstractColleague> colleagues = new Hashtable<String, AbstractColleague>();            //中介者可以动态地与某个同事建立联系      public void addColleague(String name, AbstractColleague c) {          this.colleagues.put(name, c);      }               //中介者也可以动态地撤销与某个同事的联系      public void deleteColleague(String name) {          this.colleagues.remove(name);      }            //中介者必须具备在同事之间处理逻辑、分配任务、促进交流的操作      public abstract void execute(String name, String method);   }   //具体中介者  class Mediator extends AbstractMediator{            //中介者最重要的功能，来回奔波与各个同事之间      public void execute(String name, String method) {                    if("self".equals(method)){  //各自做好分内事              if("ColleagueA".equals(name)) {                  ColleagueA colleague = (ColleagueA)super.colleagues.get("ColleagueA");                  colleague.self();              }else {                  ColleagueB colleague = (ColleagueB)super.colleagues.get("ColleagueB");                  colleague.self();              }          }else { //与其他同事合作              if("ColleagueA".equals(name)) {                  ColleagueA colleague = (ColleagueA)super.colleagues.get("ColleagueA");                  colleague.out();              }else {                  ColleagueB colleague = (ColleagueB)super.colleagues.get("ColleagueB");                  colleague.out();              }          }      }  } 
测试类：
//测试类  public class Client {      public static void main(String[] args) {                    //创建一个中介者          AbstractMediator mediator = new Mediator();                    //创建两个同事          ColleagueA colleagueA = new ColleagueA(mediator);          ColleagueB colleagueB = new ColleagueB(mediator);                    //中介者分别与每个同事建立联系          mediator.addColleague("ColleagueA", colleagueA);          mediator.addColleague("ColleagueB", colleagueB);                    //同事们开始工作          colleagueA.self();          colleagueA.out();          System.out.println("======================合作愉快，任务完成！\n");                    colleagueB.self();          colleagueB.out();          System.out.println("======================合作愉快，任务完成！");      }  } 
测试结果： 
同事A --> 做好自己分内的事情 ...  同事A --> 请求同事B做好分内工作 ...  同事B --> 做好自己分内的事情 ...  ======================合作愉快，任务完成！   同事B --> 做好自己分内的事情 ...  同事B --> 请求同事A做好分内工作  ...  同事A --> 做好自己分内的事情 ...  ======================合作愉快，任务完成！  
 
虽然以上代码中只有两个具体同事类，并且测试类中也只是创建了两个同事，但是这些我们都可以根据中介者模式的宗旨进行适当地扩展，即增加具体同事类，然后中介者就得担负更加重的任务了。为啥？我们看到上面具体中介者类Mediator中的execute()方法中现在就有一堆冗长的判断代码了。虽然可以把它分解并增加到Mediator类中的其它private方法中，但是具体的业务逻辑是少不了的。
 
所以，在解耦同事类之间的联系的同时，中介者自身也不免任务过重，因为几乎所有的业务逻辑都交代到中介者身上了，可谓是“万众期待”的一个角色了。这就是中介者模式的不足之处了 。 

此外，上面这个代码例子是相当理想的了，有时候我们根本抽取不了“同事”之间的共性来形成一个AbstractColleague抽象同事类，这也大大增加了中介者模式的使用难度。   

修改：
由于上面代码实现中存在 benjielin 前辈提出的“双向关联暴露在App中”的不足之处，根据给出的改进方法2，修改上面代码，如下：
 
修改后的同事类族：

//抽象同事类  abstract class AbstractColleague {      protected AbstractMediator mediator;                //舍去在构造函数中建立起与中介者的联系  //  public AbstractColleague(AbstractMediator mediator) {  //      this.mediator = mediator;  //  }            // 在抽象同事类中添加用于与中介者取得联系（即注册）的方法      public void setMediator(AbstractMediator mediator) {          this.mediator = mediator;      }  }   //具体同事A  class ColleagueA extends AbstractColleague {            //舍去在构造函数中建立起与中介者的联系  //  public ColleagueA(AbstractMediator mediator) {  //      super(mediator);  //  }            //每个具体同事必然有自己分内的事，没必要与外界相关联      public void self() {          System.out.println("同事A --> 做好自己分内的事情 ...");      }            //每个具体同事总有需要与外界交互的操作，通过中介者来处理这些逻辑并安排工作      public void out() {          System.out.println("同事A --> 请求同事B做好分内工作 ...");          super.mediator.execute("ColleagueB", "self");      }  }   //具体同事B  class ColleagueB extends AbstractColleague {      //舍去在构造函数中建立起与中介者的联系  //  public ColleagueB(AbstractMediator mediator) {  //      super(mediator);  //  }            public void self() {          System.out.println("同事B --> 做好自己分内的事情 ...");      }            public void out() {          System.out.println("同事B --> 请求同事A做好分内工作  ...");          super.mediator.execute("ColleagueA", "self");      }  } 

 
修改后的中介者：

//抽象中介者  abstract class AbstractMediator {            //中介者肯定需要保持有若干同事的联系方式      protected Hashtable<String, AbstractColleague> colleagues = new Hashtable<String, AbstractColleague>();            //中介者可以动态地与某个同事建立联系      public void addColleague(String name, AbstractColleague c) {                    // 在中介者这里帮助具体同事建立起于中介者的联系          c.setMediator(this);          this.colleagues.put(name, c);      }               //中介者也可以动态地撤销与某个同事的联系      public void deleteColleague(String name) {          this.colleagues.remove(name);      }            //中介者必须具备在同事之间处理逻辑、分配任务、促进交流的操作      public abstract void execute(String name, String method);   } 
//测试类  public class Client {      public static void main(String[] args) {                    //创建一个中介者          AbstractMediator mediator = new Mediator();                    //不用构造函数为具体同事注册中介者来取得联系了  //      ColleagueA colleagueA = new ColleagueA(mediator);  //      ColleagueB colleagueB = new ColleagueB(mediator);                    ColleagueA colleagueA = new ColleagueA();          ColleagueB colleagueB = new ColleagueB();                    //中介者分别与每个同事建立联系          mediator.addColleague("ColleagueA", colleagueA);          mediator.addColleague("ColleagueB", colleagueB);                    //同事们开始工作          colleagueA.self();          colleagueA.out();          System.out.println("======================合作愉快，任务完成！\n");                    colleagueB.self();          colleagueB.out();          System.out.println("======================合作愉快，任务完成！");      }  } 
  测试之后的结果与修改前一样。

本文出自 “蚂蚁” 博客，请务必保留此出处http://haolloyin.blog.51cto.com/1177454/333810[/img]..

  1、关联





双向关联：

C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。



在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。



使用ROSE 生成的代码是这样的：

class C1 

 命令模式（Command）：将一个请求封装成一个对象，使得你用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
 
命令模式，顾名思义来理解即可，就是客户端发布一个命令（也就是“请求”），而这个命令是已经被封装成一个对象的。即这个命令对象的内部可能已经指定了该命令具体被谁负责执行。就像开发经理从客户那边获取对方的需求（命令），客户在描述具体的需求可以决定是否明确指出该需求的执行方。
 
命令模式的通用类图如下： 

 
上图中，Invoker 类就相当于开发经理，ConcreteCommand 类是具体的命令，它继承自抽象命令类 Command 类，该抽象类中定义了每个命令被执行的方法 execute() 。Receiver 抽象类定义了对每一个具体的命令的执行方法 action() ,一旦接收到命令则立即行动。这里应该注意的是，每个具体的命令类都必须指定该命令的接收者，否则这命令发布了也没相应的人来完成，那就没戏了。
 
具体代码实现如下：
命令接收者相关类：
//抽象接收者，定义了每个接收者应该完成的业务逻辑  abstract class AbstractReceiver {      public abstract void doJob();  }   // 具体接收者01，实现自己真正的业务逻辑  class Receiver01 extends AbstractReceiver {      public void doJob() {          System.out.println("接收者01 完成工作 ...\n");      }  }   // 具体接收者02，实现自己真正的业务逻辑  class Receiver02 extends AbstractReceiver {      public void doJob() {          System.out.println("接收者02 完成工作 ...\n");      }  } 
命令类：
// 抽象命令类，定义了每个具体命令被执行的入口方法execute()  abstract class AbstractCommand {      public abstract void execute();  }   // 具体命令类01，通过构造函数的参数决定了该命令由哪个接收者执行  class Command01 extends AbstsractCommand {      private AbstractReceiver receiver = null;       public Command01(AbstractReceiver receiver) {          this.receiver = receiver;      }       public void execute() {                System.out.println("命令01 被发布 ...");          this.receiver.doJob();      }  }   // 具体命令类02，通过构造函数的参数决定了该命令由哪个接收者执行  class Command02 extends AbstractCommand {      private AbstractReceiver receiver = null;       public Command02(AbstractReceiver receiver) {          this.receiver = receiver;      }       public void execute() {                System.out.println("命令02 被发布 ...");          this.receiver.doJob();      }  } 
调用者类：
// 调用者，负责将具体的命令传送给具体的接收者  class Invoker {      private AbstractCommand command = null;       public void setCommand(AbstractCommand command) {          this.command = command;      }       public void action() {          this.command.execute();      }  } 
测试类：
//测试类  public class Client {      public static void main(String[] args) {          // 创建调用者          Invoker invoker = new Invoker();           // 创建一个具体命令，并指定该命令被执行的具体接收者          AbstractCommand command01 = new Command01(new Receiver01());           // 给调用者发布一个具体命令          invoker.setCommand(command01);           // 调用者执行命令，其实是将其传送给具体的接收者并让其真正执行          invoker.action();                    AbstractCommand command02 = new Command01(new Receiver02());          invoker.setCommand(command02);          invoker.action();      }  } 
测试结果：




命令01 被发布 ...
接收者01 完成工作 ...
 
命令02 被发布 ...
接收者02 完成工作 ...





 
如上面测试中输出的结果，我们知道在客户端中每次声明并创建一个具体的命令对象时总要显式地将其指定给某一具体的接收者（也就是命令的最终执行者），这似乎不太灵活，在现实中有些命令的发布也确实不是预先就指定了该命令的接收者的。
 
我们可以修改一下类图，使得客户端在有必要的时候才显式地指明命令的接收者，如下：

 
较之第一个通用类图，这里的客户 Client 类不直接与接收者 Receiver 类相关，而仅仅与调用者 Invoker 类有联系，客户发布下来的一个命令或者请求，只需要到了调用者Invoker 这里就停止了，具体怎么实现，不必对客户公开，由调用者分配即可。这里的 Command 抽象类将子类中指定具体接收者的构造函数的逻辑提取出来，由具体子类提供通过调用父类构造函数的无参、有参构造函数来实现。主要修改的是命令相关的类。 
 
具体逻辑请看下面的代码实现：
命令类：
/*   * 抽象命令类，使用构造函数的传入参数预先内定具体接收者， 若想使用其他接收者，可在子类的构造函数中传入   */ abstract class AbstractCommand {      protected AbstractReceiver receiver = null;       public AbstractCommand(AbstractReceiver receiver) {          this.receiver = receiver;      }       public abstract void execute();  }   // 具体命令类01，提供无参、有参两种构造函数  class Command01 extends AbstractCommand {       // 使用无参构造函数来默认使用的具体接收者      public Command01() {          super(new Receiver01());      }       // 使用有参构造函数来指定具体的接收者      public Command01(AbstractReceiver receiver) {          super(receiver);      }       public void execute() {                System.out.println("命令01 被发布 ...")          this.receiver.doJob();      }  }   // 具体命令类02，提供无参、有参两种构造函数  class Command02 extends AbstractCommand {       // 使用无参构造函数来默认使用的具体接收者      public Command02() {          super(new Receiver02());      }       // 使用有参构造函数来指定具体的接收者      public Command02(AbstractReceiver receiver) {          super(receiver);      }       public void execute() {                System.out.println("命令02 被发布 ...")          this.receiver.doJob();      }  } 
修改后的测试类：
// 测试类  public class Client {      public static void main(String[] args) {          // 创建调用者          Invoker invoker = new Invoker();           // 创建一个具体命令，并指定该命令被执行的具体接收者  //      AbstractCommand command01 = new Command01(new Receiver01());          AbstractCommand command01 = new Command01();           // 给调用者发布一个具体命令          invoker.setCommand(command01);           // 调用者执行命令，其实是将其传送给具体的接收者并让其真正执行          invoker.action();            //      AbstractCommand command02 = new Command01(receiver02);          AbstractCommand command02 = new Command02();          invoker.setCommand(command02);          invoker.action();                    System.out.println("\n设置命令01由接收者02执行...");          command01 = new Command01(new Receiver02());          invoker.setCommand(command01);          invoker.action();      }  } 
测试结果：




命令01 被发布 ...
接收者01 完成工作 ...
 
命令02 被发布 ...
接收者02 完成工作 ...
 
设置命令01由接收者02执行...
命令01 被发布 ...
接收者02 完成工作 ...





 

此时在客户端中，我们不指明一个命令的具体接收者（执行者）也同样可以达到第一种实现方法中的效果。此外，客户也可以显式指出具体接收者，就像上面那样。
命令模式的优点：

1、 调用者与接收者没有任何的依赖关系，它们时通过具体的命令的存在而存在的；
2、 若有多个具体命令，只要扩展 Command 的子类即可，同样地具体接收者也可以相对应地进行扩展；
 
命令模式的缺点：其实上面优点中第2点在一定场景中也会变成缺点。如果具体的命令有很多个，那么子类就必然会暴增、膨胀。
 
但是，上面的具体代码实现中这种设计似乎也不太乐观，原因是每一个具体的命令都是由一个具体的接收者来执行的，在多交互的场景中这显然是太理想化的。于是，我想到了中介者模式（Mediator）中最主要的 Mediator 类中预先地注册了业务中需要交互的同事类的对象，接下来每一次交互逻辑都交给 Mediator 来“暗箱”操作。
 
根据上一段的想法，我们可以在抽象命令 Command 类中预先注册一定数量的具体接收者，那么具体命令中就可以决定是否要在多个接收者中进行协作完成了，这种协作的代码逻辑则应该写在覆盖父类的execute() 方法中，而在 execute() 方法中又可以运用模板方法模式（Template Method）进行设计。[/img]..

 职责链模式（Chain of Responsibility）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
适用场景：
1、有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定；
2、在不明确指定接收者的情况下，向多个对象中的一个提交一个请求；
3、处理一个请求的对象集合应被动态指定。
通用类图：

在大学里面当班干部，时常要向上级申请各方面的东西。譬如申请全班外出秋游，普通同学将申请表交给班长，班长签字之后交给辅导员，辅导员批准之后上交到主任办公室…就是这样，一个请求（这里是一份申请表）有时候需要经过好几个级别的处理者（这里是辅导员、主任）的审查才能够最终被确定可行与否。
在这里表现出来的是一个职责链，即不同的处理者对同一个请求可能担负着不同的处理方式、权限，但是我们希望这个请求必须到达最终拍板的处理者（否则秋游就没戏了）。这种关系就很适合使用职责链模式了。
类图结构如下：
 代码实现如下：
// 全局变量，接口类型  /**   * 使用Java中的interface定义全局变量，可根据具体需要在    * 具体的包中使用静态导入相关的全局变量，语法如下：    *  import static package01.package02.*;   */ interface Levels {      public static final int LEVEL_01 = 1;      public static final int LEVEL_02 = 2;      public static final int LEVEL_03 = 3;  } 
 
// 抽象请求类  abstract class AbstractRequest {      private String content = null;       public AbstractRequest(String content) {          this.content = content;      }       public String getContent() {          return this.content;      }       // 获得请求的级别      public abstract int getRequestLevel();  } 
 
// 具体请求类01  class Request01 extends AbstractRequest {      public Request01(String content) {          super(content);      }       @Override     public int getRequestLevel() {          return Levels.LEVEL_01;      }  }   // 具体请求类02  class Request02 extends AbstractRequest {      public Request02(String content) {          super(content);      }       @Override     public int getRequestLevel() {          return Levels.LEVEL_02;      }  }   // 具体请求类03  class Request03 extends AbstractRequest {      public Request03(String content) {          super(content);      }       @Override     public int getRequestLevel() {          return Levels.LEVEL_03;      }  } 
 
// 抽象处理者类，  abstract class AbstractHandler {      // 责任链的下一个节点，即处理者      private AbstractHandler nextHandler = null;       // 捕获具体请求并进行处理，或是将请求传递到责任链的下一级别      public final void handleRequest(AbstractRequest request) {           // 若该请求与当前处理者的级别层次相对应，则由自己进行处理          if (this.getHandlerLevel() == request.getRequestLevel()) {              this.handle(request);          } else {              // 当前处理者不能胜任，则传递至职责链的下一节点              if (this.nextHandler != null) {                  System.out.println("当前 处理者-0" + this.getHandlerLevel()                          + " 不足以处理 请求-0" + request.getRequestLevel());                                    // 这里使用了递归调用                  this.nextHandler.handleRequest(request);              } else {                  System.out.println("职责链上的所有处理者都不能胜任该请求...");              }          }      }       // 设置责任链中的下一个处理者      public void setNextHandler(AbstractHandler nextHandler) {          this.nextHandler = nextHandler;      }       // 获取当前处理者的级别      protected abstract int getHandlerLevel();       // 定义链中每个处理者具体的处理方式      protected abstract void handle(AbstractRequest request);  } 
 
// 具体处理者-01  class Handler01 extends AbstractHandler {      @Override     protected int getHandlerLevel() {          return Levels.LEVEL_01;      }       @Override     protected void handle(AbstractRequest request) {          System.out.println("处理者-01 处理 " + request.getContent() + "\n");      }  }   // 具体处理者-02  class Handler02 extends AbstractHandler {      @Override     protected int getHandlerLevel() {          return Levels.LEVEL_02;      }       @Override     protected void handle(AbstractRequest request) {          System.out.println("处理者-02 处理 " + request.getContent()+ "\n");      }  }   // 具体处理者-03  class Handler03 extends AbstractHandler {      @Override     protected int getHandlerLevel() {          return Levels.LEVEL_03;      }       @Override     protected void handle(AbstractRequest request) {          System.out.println("处理者-03 处理 " + request.getContent()+ "\n");      }  } 
 
// 测试类  public class Client {      public static void main(String[] args) {          // 创建指责链的所有节点          AbstractHandler handler01 = new Handler01();          AbstractHandler handler02 = new Handler02();          AbstractHandler handler03 = new Handler03();           // 进行链的组装，即头尾相连，一层套一层          handler01.setNextHandler(handler02);          handler02.setNextHandler(handler03);           // 创建请求并提交到指责链中进行处理          AbstractRequest request01 = new Request01("请求-01");          AbstractRequest request02 = new Request02("请求-02");          AbstractRequest request03 = new Request03("请求-03");                    // 每次提交都是从链头开始遍历          handler01.handleRequest(request01);          handler01.handleRequest(request02);          handler01.handleRequest(request03);      }  } 
测试结果：
处理者-01 处理 请求-01  当前 处理者-01 不足以处理 请求-02 处理者-02 处理 请求-02  当前 处理者-01 不足以处理 请求-03 当前 处理者-02 不足以处理 请求-03 处理者-03 处理 请求-03 
在上面抽象处理者 AbstractHandler 类的 handleRequest() 方法中，被 protected 修饰，并且该方法中调用了两个必须被子类覆盖实现的抽象方法，这里是使用了模板方法模式（Template Mehtod）。其实在这里，抽象父类的 handleRequest() 具备了请求传递的功能，即对某些请求不能处理时，马上提交到下一结点（处理者）中，而每个具体的处理者仅仅完成了具体的处理逻辑，其他的都不用理。
 
记得第一次看到职责链模式的时候，我很惊讶于它能够把我们平时在代码中的 if..else.. 的语句块变成这样灵活、适应变化。例如：如果现在辅导员请长假了，但我们的秋游还是要争取申请成功呀，那么我们在 Client 类中可以不要创建 handler02，即不要将该处理者组装到职责链中。这样子处理比 if..else..好多了。或者说，突然来了个爱管闲事的领导，那么我照样可以将其组装到职责链中。
 
关于上面使用场景中提到的3个点：
1、处理者在运行时动态确定其实是我们在 Client 中组装的链所引起的，因为具体的职责逻辑就在链中一一对应起来；
2、因为不确定请求的具体处理者是谁，所以我们把所有可能的处理者组装成一条链，在遍历的过程中就相当于向每个处理者都提交了这个请求，等待其审查。并且在审查过程中，即使不是最终处理者，也可以进行一些请求的“包装”操作（这种功能类似于装饰者模式），例如上面例子中的签名批准；
3、处理者集合的动态指定跟上面的第1、2点类似，即在 Client 类中创建了所有可能的处理者。
 
不足之处：
1、对于每一个请求都需要遍历职责链，性能是个问题；
2、抽象处理者 AbstractHandler 类中的 handleRequest() 方法中使用了递归，栈空间的大小也是个问题。
 个人看法：
职责链模式对于请求的处理是不知道最终处理者是谁，所以是运行动态寻找并指定；而命令模式中对于命令的处理时在创建命令是已经显式或隐式绑定了接收者。
相关文章：
命令模式（Command）的两种不同实现（http://haolloyin.blog.51cto.com/1177454/339076）
（Template Method）模板方法模式的Java实现（http://haolloyin.blog.51cto.com/1177454/333063）
装饰模式（Decorator）与动态代理的强强联合（http://haolloyin.blog.51cto.com/1177454/338671）
本文出自 “蚂蚁” 博客，请务必保留此出处http://haolloyin.blog.51cto.com/1177454/342166[/img]..

   
一、 抽象工厂（Abstract Factory）模式
抽象工厂模式是所有形态的工厂模式中最为抽象和最具一般性的一种形态。
为了方便引进抽象工厂模式，引进一个新概念：产品族（Product Family）。所谓产品族，是指位于不同产品等级结构，功能相关联的产品组成的家族。如图：
 
图中一共有四个产品族，分布于三个不同的产品等级结构中。只要指明一个产品所处的产品族以及它所属的等级结构，就可以唯一的确定这个产品。
引进抽象工厂模式
所谓的抽象工厂是指一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象。如果用图来描述的话，如下图：
 
二、 Abstract Factory模式的结构：
 



图中描述的东西用产品族描述如下：
 

 原型模式（Prototype）：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
当我们已经拥有某个得来不易的宝贝时，往往我们会很想再“变”一些出来，即这个宝贝的“复制品”，这种方式简单又理想，谁都想要学会这项本事。不可能的事情！不过，这种手段在软件设计中是完全可以实现的，在OO中的原型模式就是这样基于思想的。
原型模式的适用场景：（摘录自《设计模式迷你手册》）
1、当要实例化的类是在运行时刻指定时，例如，通过动态装载；
2、为了避免创建一个与产品类层次平行的工厂..

 代理模式是一种非常重要的设计模式，在Java语言中有着广泛的应用，包括Spring AOP的核心设计思想，都和代理模式有密切关系。
 
代理模式主要分两种：一种是静态代理，一种是动态代理。两种代理方式的实现有着本质的差异。
 
代理模式的作用是：为其他对象提供一种代理以控制对这个对象的访问。在某些情况下，一个客户不想或者不能直接引用另一个对象，而代理对象可以在客户端和目标对象之间起到中介的作用。
 
代理模式一般涉及到的角色有：
抽象角色：声明真实对象和代理对象的共同接口。
代理角色：代..