一、学习设计模式最重要的是了解模式的应用场景。编程遇到特定场景的话，要有意识联想到设计模式，哪怕细节忘了也没关系，翻翻书就找到了。

二、提高设计的思想。学习设计模式的时候，要体会模式精妙之处，当想明白大师思想和自己的差距的时候，差距就缩短了一点儿。

有的模式平淡无奇，应用却广泛。有的模式设计精巧，应用场景却不易遇到。无论如何，要么掌握工具，要么学到思想，都是收获。

最适合简单概括设计模式的是UML图，收集了一个非常好的资源，分享在我的sky drive网络硬盘上，包含23种设计模式的UML图

http://cid-d8b11f9bf86fecfa.office.live.com/self.aspx/.Public/books/designpatternscard.pdf

设计模式可以分为三类：behavioural, structural, creational

behavioural 11 种

1. Memento（备忘录）

精巧程度： 5星

应用广泛：2星

memento适合保存/恢复状态的场景。分为宽接口和窄接口。学习就要学窄接口！

具体请见： http://www.blogjava.net/vcycyv/archive/2011/02/08/343949.html

2. Chain of Responsibility(责任链)

精巧程度： 3星

应用广泛： 3星

适合用在"一系列handler”的场景下。分为纯和不纯两种，好像女孩儿也可以这么分？

具体请见：

http://www.blogjava.net/vcycyv/archive/2011/02/12/344167.html

3. Observer（观察者）

因为java里有Obserable和Observer， 所以通常在java里不会自己设计观察者模式。

4. Command(命令模式)

精巧程度：4星

应用广泛：3星

command模式用来解耦invoker和receiver.

具体请见：

http://www.blogjava.net/vcycyv/archive/2011/02/12/344168.html

5. State(状态模式)

精巧程度：4星

应用广泛：3星

OO编程如果出现多个相同的if…else条件，应该考虑用state模式重构。work flow的状态器也是基于State模式的。

具体请见：

http://www.blogjava.net/vcycyv/archive/2011/02/09/343998.html

6. Interpreter

精巧程度： N/A

应用广泛： 1星

据说只有搜索引擎才用得上这个模式，反正我每次学设计模式的时候，都把这个跳过去，就是不喜欢，抱歉。

7. Strategy（策略模式）

精巧程度： 2星

应用广泛：4星

用来封装不同算法。从uml图上看和state模式一样。 因为这个太简单了，所以没记笔记，这个忘不了。

8. Iterator(迭代子)

Java Collection都可以迭代，在java上不需要格外设计iterator。

9. Template Method(模板方法)

精巧程度：2星

应用广泛：4星

见名知义。太简单了，学过一遍就不会忘。但是这个应用非常广泛！

10. Mediator(仲裁者)

精巧程度：4星

应用广泛：1星

用来解耦多个peer。个人觉得这个模式多半会让mediator十分臃肿，mediator本身需要有很清晰的设计才能使用。应用场景恐怕也少。

具体请见：

http://www.blogjava.net/vcycyv/archive/2011/02/08/343951.html

11. Visitor(访问者)

精巧程度：5星

应用广泛：2星

collection里存一个类系的entry时，使用visitor模式可以避免instance of的使用。更重要的是方便扩展类系。

具体请见：

http://www.blogjava.net/vcycyv/archive/2011/02/13/344194.html

Structure 7种

12. adapter(适配器)

精巧程度：2星

应用广泛：1星

个人觉得Adaptee由第三方提供的时候才可能用上这个模式[vcycyv编辑：后来意识到，这个评论不客观。adaptee实现核心功能，通过adapter暴露多种访问方式的情况下，adaptee也是自己写的，而不是第三方的]。简单应用范围又窄，略

13. Proxy(代理)

精巧程度：2星

应用广泛：5星

aop是代理模式的一种发挥。Spring和Hibernate都大量使用proxy。可以引申学学JDK的dynamic proxy。模式简单，略。

14. Bridge

精巧程度： 5星

应用广泛： 3星

Bridge在技术上是strategy的进一步发挥，但侧重在实现与抽象的解耦。

具体见：

http://www.blogjava.net/vcycyv/archive/2011/02/08/343950.html

15. Composite

精巧程度： 4星

应用广泛： 3星

适用于树状结构。

具体见：

http://www.blogjava.net/vcycyv/archive/2011/02/13/344209.html

16. Decorator(装饰)

精巧程度： 5星

应用广泛：3星

在java I/O中广泛使用。为了解决“类爆炸”的问题。

具体请见：

http://www.blogjava.net/vcycyv/archive/2011/02/09/343997.html

17. Facade(门面)

连个UML图都没有，算神马模式？

18. Flyweight

精巧程度：5星

应用广泛：2星

分“单纯”“复合”两种，本身包含了工厂方法模式。一系列对象如果他们都有某部分属于特定集合，就让他们共享这个特定集合以节省资源。

具体请见：

http://www.blogjava.net/vcycyv/archive/2011/02/12/344169.html

Creational 6 种

19. Factory Method(工厂方法)

精巧程度：3星

应用广泛：4星

两个变种，一个是根据参数创建对象，一个是factory类系对应产品类系。面向接口编程在创建模式的体现。

具体请见：

http://www.blogjava.net/vcycyv/archive/2011/02/13/344176.html

20. Abstract Factory（抽象工厂）

精巧程度：5星

应用广泛：1星

只有产品有两个类系的时候才用得上。

具体请见：

http://www.blogjava.net/vcycyv/archive/2011/02/15/344390.html

21. Builder

精巧程度： 5星

应用广泛： 2星

产品分部分，并且build的过程不定的时候考虑用这种模式。是模板模式的一种发挥

具体请见：

http://www.blogjava.net/vcycyv/archive/2011/02/09/343995.html

22. Prototype(原型)

java有cloneable的支持，所以通常不需要自己设计prototype. java用prototype的时候注意深复制浅复制的问题。prototype之外的一个选择是提供一个constructor接受本类型对象作为参数，这个方式更加实用！

23. singleton(单态)

古典的singleton分为懒汉，饿汉两种。JDK1.5之后可以用唯一entry 的enum作为singleton的实现。好处有两点，一是简单。二是不需要格外处理serializable的情况

When dealing with tree-structured data, programmers often have to discriminate between a leaf-node and a branch. This makes code more complex, and therefore, error prone. The solution is an interface that allows treating complex and primitive objects uniformly. In object-oriented programming, a composite is an object designed as a composition of one-or-more similar objects, all exhibiting similar functionality. This is known as a "has-a" relationship between objects^[2]. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them. The operations you can perform on all the composite objects often have a least common denominator relationship. For example, if defining a system to portray grouped shapes on a screen, it would be useful to define resizing a group of shapes to have the same effect (in some sense) as resizing a single shape.

   1: import java.util.ArrayList;

   2:  

   3: /** "Component" */

   4: interface Graphic {

   5:  

   6:     //Prints the graphic.

   7:     public void print();

   8: }

   9:  

  10: /** "Composite" */

  11: class CompositeGraphic implements Graphic {

  12:  

  13:     //Collection of child graphics.

  14:     private List<Graphic> mChildGraphics = new ArrayList<Graphic>();

  15:  

  16:     //Prints the graphic.

  17:     public void print() {

  18:         for (Graphic graphic : mChildGraphics) {

  19:             graphic.print();

  20:         }

  21:     }

  22:  

  23:     //Adds the graphic to the composition.

  24:     public void add(Graphic graphic) {

  25:         mChildGraphics.add(graphic);

  26:     }

  27:  

  28:     //Removes the graphic from the composition.

  29:     public void remove(Graphic graphic) {

  30:         mChildGraphics.remove(graphic);

  31:     }

  32: }

  33:  

  34: /** "Leaf" */

  35: class Ellipse implements Graphic {

  36:  

  37:     //Prints the graphic.

  38:     public void print() {

  39:         System.out.println("Ellipse");

  40:     }

  41: }

  42:  

  43: /** Client */

  44: public class Program {

  45:  

  46:     public static void main(String[] args) {

  47:         //Initialize four ellipses

  48:         Ellipse ellipse1 = new Ellipse();

  49:         Ellipse ellipse2 = new Ellipse();

  50:         Ellipse ellipse3 = new Ellipse();

  51:         Ellipse ellipse4 = new Ellipse();

  52:  

  53:         //Initialize three composite graphics

  54:         CompositeGraphic graphic = new CompositeGraphic();

  55:         CompositeGraphic graphic1 = new CompositeGraphic();

  56:         CompositeGraphic graphic2 = new CompositeGraphic();

  57:  

  58:         //Composes the graphics

  59:         graphic1.add(ellipse1);

  60:         graphic1.add(ellipse2);

  61:         graphic1.add(ellipse3);

  62:  

  63:         graphic2.add(ellipse4);

  64:  

  65:         graphic.add(graphic1);

  66:         graphic.add(graphic2);

  67:  

  68:         //Prints the complete graphic (four times the string "Ellipse").

  69:         graphic.print();

  70:     }

  71: }

Example
The following example is in the Java programming language, and shows how the contents of a tree of nodes (in this case describing the components of a car) can be printed. Instead of creating "print" methods for each subclass (Wheel, Engine, Body, and Car), a single class (CarElementPrintVisitor) performs the required printing action. Because different subclasses require slightly different actions to print properly, CarElementDoVisitor dispatches actions based on the class of the argument passed to it.

interface CarElementVisitor {
    void visit(Wheel wheel);
    void visit(Engine engine);
    void visit(Body body);
    void visit(Car car);
}
interface CarElement {
    void accept(CarElementVisitor visitor); // CarElements have to provide accept().
}
class Wheel implements CarElement {
    private String name;
    public Wheel(String name) {
        this.name = name;
    }
    public String getName() {
        return this.name;
    }
    public void accept(CarElementVisitor visitor) {
        visitor.visit(this);
    }
}
class Engine implements CarElement {
    public void accept(CarElementVisitor visitor) {
        visitor.visit(this);
    }
}
class Body implements CarElement {
    public void accept(CarElementVisitor visitor) {
        visitor.visit(this);
    }
}
class Car implements CarElement{
    CarElement[] elements;
    public CarElement[] getElements() {
        return elements.clone(); // Return a copy of the array of references.
    }
    public Car() {
        this.elements = new CarElement[]
          { new Wheel("front left"), new Wheel("front right"),
            new Wheel("back left") , new Wheel("back right"),
            new Body(), new Engine() };
    }
    public void accept(CarElementVisitor visitor) {
        for(CarElement element : this.getElements()) {
            element.accept(visitor);
        }
        visitor.visit(this);
    }
}
class CarElementPrintVisitor implements CarElementVisitor {
    public void visit(Wheel wheel) {    
        System.out.println("Visiting "+ wheel.getName()
                            + " wheel");
    }
    public void visit(Engine engine) {
        System.out.println("Visiting engine");
    }
    public void visit(Body body) {
        System.out.println("Visiting body");
    }
    public void visit(Car car) {    
        System.out.println("Visiting car");
    }
}
class CarElementDoVisitor implements CarElementVisitor {
    public void visit(Wheel wheel) {
        System.out.println("Kicking my "+ wheel.getName() + " wheel");
    }
    public void visit(Engine engine) {
        System.out.println("Starting my engine");
    }
    public void visit(Body body) {
        System.out.println("Moving my body");
    }
    public void visit(Car car) {
        System.out.println("Starting my car");
    }
}
public class VisitorDemo {
    static public void main(String[] args){
        Car car = new Car();
        car.accept(new CarElementPrintVisitor());
        car.accept(new CarElementDoVisitor());
    }
} 

FactoryMethod是一种创建性模式,它定义了一个创建对象的接口,但是却让子类来决定具体实例化哪一个类.当一个类无法预料要创建哪种类的对象或是一个类需要由子类来指定创建的对象时我们就需要用到Factory Method 模式了.简单说来,Factory Method可以根据不同的条件产生不同的实例,当然这些不同的实例通常是属于相同的类型,具有共同的父类.Factory Method把创建这些实例的具体过程封装起来了,简化了客户端的应用,也改善了程序的扩展性,使得将来可以做最小的改动就可以加入新的待创建的类. 通常我们将Factory Method作为一种标准的创建对象的方法,当发现需要更多的灵活性的时候,就开始考虑向其它创建型模式转化

简单分析

图1是Factory Method 模式的结构图,这里提供了一些术语,让我们可以进行更方便的描述:

1. Product: 需要创建的产品的抽象类.
2. ConcreteProduct: Product的子类,一系列具体的产品.
3. Creator: 抽象创建器接口,声明返回Product类型对象的Factory Method.
4. ConcreteCreator: 具体的创建器,重写Creator中的Factory Method,返回ConcreteProduct类型的实例.

由此可以清楚的看出这样的平行对应关系: Product <====> Creator ; ConreteProduct <====> ConreteCreator

抽象产品对应抽象创建器,具体产品对应具体创建器.这样做的好处是什么呢?为什么我们不直接用具体的产品和具体的创建器完成需求呢?实际上我们也可以这样做.但通过Factory Method模式来完成,客户(client)只需引用抽象的Product和Creater,对具体的ConcreteProduct和ConcreteCreator可以毫不关心,这样做我们可以获得额外的好处:

• 首先客户端可以统一从抽象创建器获取产生的实例,Creator的作用将client和产品创建过程分离开来,客户不用操心返回的是那一个具体的产品,也不用关心这些产品是如何创建的.同时,ConcreteProduct也被隐藏在Product后面,ConreteProduct继承了Product的所有属性,并实现了Product中定义的抽象方法,按照Java中的对象造型(cast)原则,通过ConcreteCreator产生的ConcreteProduct可以自动的上溯造型成Product.这样一来,实质内容不同的ConcreteProduct就可以在形式上统一为Product,通过Creator提供给client来访问.
• 其次,当我们添加一个新的ConcreteCreator时,由于Creator所提供的接口不变,客户端程序不会有丝毫的改动,不会带来动一发而牵全身的灾难, 这就是良好封装性的体现.但如果直接用ConcreteProduct和ConcreteCreator两个类是无论如何也做不到这点的. 优良的面向对象设计鼓励使用封装(encapsulation)和委托(delegation),而Factory Method模式就是使用了封装和委托的典型例子,这里封装是通过抽象创建器Creator来体现的,而委托则是通过抽象创建器把创建对象的责任完全交给具体创建器ConcreteCreator来体现的.

现在,请再回头看看基本概念中的那段话,开始也许觉得生涩难懂,现在是不是已经明朗化了很多.

下面让我们看看在 Java 中如何实现Factory Method模式,进一步加深对它的认识.

具体实施

先说明一点,用Factory Method模式创建对象并不一定会让我们的代码更短,实事上往往更长,我们也使用了更多的类,真正的目的在于这样可以灵活的,有弹性的创建不确定的对象.而且,代码的可重用性提高了,客户端的应用简化了,客户程序的代码会大大减少,变的更具可读性.

1. 标准实现: 这里我采用Bruce Eckel 用来描述OO思想的经典例子 Shape.这样大家会比较熟悉一些.我完全按照图1中所定义的结构写了下面的一段演示代码.这段代码的作用是创建不同的Shape实例,每个实例完成两个操作:draw和erase.具体的创建过程委托�oShapeFactory来完成.

   1.a 首先定义一个抽象类Shape,定义两个抽象的方法.

   abstract class Shape {
     // 勾画shape
     public abstract void draw();
     // 擦去 shape
     public abstract void erase();
     public String name;
     public Shape(String aName){
       name = aName;
     }
   }

   1.b 定义 Shape的两个子类: Circle, Square,实现Shape中定义的抽象方法

   // 圆形子类
   class Circle extends Shape {
     public void draw() {
       System.out.println("It will draw a circle.");
     }
     public void erase() {
       System.out.println("It will erase a circle."); 
     }
     // 构造函数
     public Circle(String aName){
       super(aName);
     }
   }
   // 方形子类
   class Square extends Shape {
     public void draw() { 
       System.out.println("It will draw a square."); 
     }
     public void erase() { 
       System.out.println("It will erase a square."); 
     }
     // 构造函数
     public Square(String aName){
       super(aName);
     }
   }
   

   1.c 定义抽象的创建器,anOperation调用factoryMethod创建一个对象,并对该对象进行一系列操作.

   abstract class ShapeFactory {  
     protected abstract Shape factoryMethod(String aName);
     // 在anOperation中定义Shape的一系列行为
   public void anOperation(String aName){
       Shape s = factoryMethod(aName);
       System.out.println("The current shape is: " + s.name);
       s.draw();
       s.erase();
     }
   }

   1.d 定义与circle和square相对应的两个具体创建器CircleFactory,SquareFactory,实现父类的methodFactory方法

   // 定义返回 circle 实例的 CircleFactory
   class CircleFactory extends ShapeFactory {
     // 重载factoryMethod方法,返回Circle对象
     protected Shape factoryMethod(String aName) {
       return new Circle(aName + " (created by CircleFactory)");
     }
   }
     
   // 定义返回 Square 实例的 SquareFactory
   class SquareFactory extends ShapeFactory {
     // 重载factoryMethod方法,返回Square对象
   protected Shape factoryMethod(String aName) {
       return new Square(aName + " (created by SquareFactory)");
     }
   }
   

   1.e 测试类:请注意这个客户端程序多么简洁,既没有罗嗦的条件判断语句,也无需关心ConcreteProduct和ConcreteCreator的细节(因为这里我用anOperation封装了Product里的两个方法,所以连Product的影子也没看见,当然把Product里方法的具体调用放到客户程序中也是不错的).

   class Main {
     public static void main(String[] args){
       ShapeFactory sf1 = new SquareFactory(); 
       ShapeFactory sf2 = new CircleFactory();
       sf1.anOperation("Shape one");
       sf2.anOperation("Shape two");
     }
   }  
   

   运行结果如下:

   The current shape is: Shape one (created by SquareFactory)

   It will draw a square.

   It will erase a square.

   The current shape is: Shape two (created by CircleFactory)

   It will draw a circle.

   It will erase a circle.

2. 参数化的Factory Method: 这种方式依靠指定的参数作为标志来创建对应的实例,这是很常见的一种办法.比如JFC中的BorderFactory就是个很不错的例子. 以下的这个例子是用字符串作为标记来进行判断的,如果参数的类型也不一样,那就可以用到过载函数来解决这个问题,定义一系列参数和方法体不同的同名函数,这里java.util.Calendar.getInstance()又是个极好的例子.参数化的创建方式克服了Factory Method模式一个最显著的缺陷,就是当具体产品比较多时,我们不得不也建立一系列与之对应的具体构造器. 但是在客户端我们必须指定参数来决定要创建哪一个类.

   2.a 我们在第一种方法的基础上进行修改,首先自定义一个的异常,这样当传入不正确的参数时可以得到更明显的报错信息.

   class NoThisShape extends Exception {
     public NoThisShape(String aName) {
       super(aName);
     }
   }
   

   2.b去掉了ShapeFactory的两个子类,改为由ShapeFactory直接负责实例的创建. ShapeFactory自己变成一个具体的创建器,直接用参数化的方法实现factoryMethod返回多种对象.

   abstract class ShapeFactory {  
     private static Shape s;
     private ShapeFactory() {}
       
     static Shape factoryMethod(String aName, String aType) throws NoThisShape{
       if (aType.compareTo("square")==0)
         return new Square(aName);
       else if (aType.compareTo("circle")==0)
         return new Circle(aName);
       else throw new NoThisShape(aType);  
     }
     
     // 在anOperation中定义Shape的一系列行为
     static void anOperation(String aName, String aType) throws NoThisShape{
       s = factoryMethod(aName, aType);
       System.out.println("The current shape is: " + s.name);
       s.draw();
       s.erase();
     }
   }
   

   2.c 测试类:这里客户端必须指定参数来决定具体创建哪个类.这个例子里的anOperation是静态函数,可以直接引用.

   class Main {
     public static void main(String[] args) throws NoThisShape{
       ShapeFactory.anOperation("Shape one","circle");
       ShapeFactory.anOperation("Shape two","square");
       ShapeFactory.anOperation("Shape three", "delta");
     }
   }
   

   运行结果如下:

   The current shape is: Shape one
   It will draw a circle.
   It will erase a circle.
   The current shape is: Shape two
   It will draw a square.
   It will erase a square.
   Exception in thread "main" NoThisShape: delta
           at ShapeFactory.factoryMethod(ShapeFactory.java:10)
           at ShapeFactory.anOperation(ShapeFactory.java:15)
           at Main.main(Main.java:5)
   

3. 动态装载机制:

   有的时候我们会把ConcreteProduct的实例传给创建器作为参数,这种情况下,如果在创建器里完成创建过程,就必须判断参数的具体类型(用instanceof),然后才能产生相应的实例,那么比较好的做法是利用Java的动态装载机制来完成这件事.比如:

   我们得到一个Shape的子类s,但不知道具体是那个子类,就可以利用Class类自带的方法newInstance()得到实例

   return (Shape)s.getClass().newInstance();

   这种方法有兴趣得读者可以自己尝试,限于篇幅,不写具体代码出来了.

/*the Invoker class*/
public class Switch {
 
    private Command flipUpCommand;
    private Command flipDownCommand;
 
    public Switch(Command flipUpCmd, Command flipDownCmd) {
         this.flipUpCommand = flipUpCmd;
         this.flipDownCommand = flipDownCmd;
    }
 
    public void flipUp() {
         flipUpCommand.execute();
    }
 
    public void flipDown() {
         flipDownCommand.execute();
    }
}
 
/*Receiver class*/
public class Light {
 
     public Light() {  }
 
     public void turnOn() {
        System.out.println("The light is on");
     }
 
     public void turnOff() {
        System.out.println("The light is off");
     }
}
 
/*the Command interface*/
public interface Command {
    void execute();
}
 
/*the Command for turning on the light*/
public class FlipUpCommand implements Command {
 
   private Light theLight;
 
   public FlipUpCommand(Light light) {
        this.theLight=light;
   }
 
   public void execute(){
      theLight.turnOn();
   }
}
 
/*the Command for turning off the light*/
public class FlipDownCommand implements Command {
 
   private Light theLight;
 
   public FlipDownCommand(Light light) {
        this.theLight=light;
   }
 
   public void execute() {
      theLight.turnOff();
   }
}
 
/*The test class or client*/
public class PressSwitch {
 
   public static void main(String[] args) {
       Light lamp = new Light();
       Command switchUp = new FlipUpCommand(lamp);
       Command switchDown = new FlipDownCommand(lamp);
 
       // See criticism of this model above:
       // The switch itself should not be aware of lamp details (switchUp, switchDown) 
       // either directly or indirectly
       Switch s = new Switch(switchUp,switchDown);
 
       try {
           if (args[0].equalsIgnoreCase("ON")) {
                s.flipUp();
           } else if (args[0].equalsIgnoreCase("OFF")) {
               s.flipDown();
           } else {
               System.out.println("Argument \"ON\" or \"OFF\" is required.");
           }
       } catch (Exception e){
           System.out.println("Arguments required.");
       }
   }
}
=====================

java tip (http://www.javaworld.com/javaworld/javatips/jw-javatip68.html?page=3) 给了类似的例子，多了Fan作为receiver:

TestCommand.java
class Fan {
        public void startRotate() {
                System.out.println("Fan is rotating");
        }
        public void stopRotate() {
                System.out.println("Fan is not rotating");
        }
}
class Light {
        public void turnOn( ) {
                System.out.println("Light is on ");
        }
        public void turnOff( ) {
                System.out.println("Light is off");
        }
}
class Switch {
        private Command UpCommand, DownCommand;
        public Switch( Command Up, Command Down) {
                UpCommand = Up; // concrete Command registers itself with the invoker
                DownCommand = Down;
        }
        void flipUp( ) { // invoker calls back concrete Command, which executes the Command on the receiver
                        UpCommand . execute ( ) ;                          
        }
        void flipDown( ) {
                        DownCommand . execute ( );
        }
}
class LightOnCommand implements Command {
        private Light myLight;
        public LightOnCommand ( Light L) {
                myLight  =  L;
        }
        public void execute( ) {
                myLight . turnOn( );
        }
}
class LightOffCommand implements Command {
        private Light myLight;
        public LightOffCommand ( Light L) {
                myLight  =  L;
        }
        public void execute( ) {
                myLight . turnOff( );
        }
}
class FanOnCommand implements Command {
        private Fan myFan;
        public FanOnCommand ( Fan F) {
                myFan  =  F;
        }
        public void execute( ) {
                myFan . startRotate( );
        }
}
class FanOffCommand implements Command {
        private Fan myFan;
        public FanOffCommand ( Fan F) {
                myFan  =  F;
        }
        public void execute( ) {
                myFan . stopRotate( );
        }
}
public class TestCommand {
                public static void main(String[] args) {
                        Light  testLight = new Light( );
                        LightOnCommand testLOC = new LightOnCommand(testLight);
                        LightOffCommand testLFC = new LightOffCommand(testLight);
                        Switch testSwitch = new Switch( testLOC,testLFC);      
                        testSwitch.flipUp( );
                        testSwitch.flipDown( );
                        Fan testFan = new Fan( );
                        FanOnCommand foc = new FanOnCommand(testFan);
                        FanOffCommand ffc = new FanOffCommand(testFan);
                        Switch ts = new Switch( foc,ffc);
                        ts.flipUp( );
                        ts.flipDown( );
                }
}              
Command.java
public interface Command {
        public abstract void execute ( );
}

Writing to stdout: Entering function y. Writing to stdout: Step1 completed. Sending via e-mail: Step1 completed. Writing to stdout: An error has occurred. Sending via e-mail: An error has occurred. Writing to stderr: An error has occurred.

Note that this example should not be seen as a recommendation on how to write logging classes.

Also, note that in a 'pure' implementation of the chain of responsibility pattern, a logger would not pass responsibility further down the chain after handling a message. In this example, a message will be passed down the chain whether it is handled or not.

import java.util.*;
abstract class Logger
{
    public static int ERR = 3;
    public static int NOTICE = 5;
    public static int DEBUG = 7;
    protected int mask;
    // The next element in the chain of responsibility
    protected Logger next;
    public Logger setNext( Logger l )
    {
        next = l;
        return l;
    }
    public void message( String msg, int priority )
    {
        if ( priority <= mask )
        {
            writeMessage( msg );
        }
        if ( next != null )
        {
            next.message( msg, priority );
        }
    }
    abstract protected void writeMessage( String msg );
}
class StdoutLogger extends Logger
{
    public StdoutLogger( int mask ) { this.mask = mask; }
    protected void writeMessage( String msg )
    {
        System.out.println( "Writing to stdout: " + msg );
    }
}
class EmailLogger extends Logger
{
    public EmailLogger( int mask ) { this.mask = mask; }
    protected void writeMessage( String msg )
    {
        System.out.println( "Sending via email: " + msg );
    }
}
class StderrLogger extends Logger
{
    public StderrLogger( int mask ) { this.mask = mask; }
    protected void writeMessage( String msg )
    {
        System.err.println( "Sending to stderr: " + msg );
    }
}
public class ChainOfResponsibilityExample
{
    public static void main( String[] args )
    {
        // Build the chain of responsibility
        Logger l,l1;
        l1 = l = new StdoutLogger( Logger.DEBUG );
        l1 = l1.setNext(new EmailLogger( Logger.NOTICE ));
        l1 = l1.setNext(new StderrLogger( Logger.ERR ));
        // Handled by StdoutLogger
        l.message( "Entering function y.", Logger.DEBUG );
        // Handled by StdoutLogger and EmailLogger
        l.message( "Step1 completed.", Logger.NOTICE );
        // Handled by all three loggers
        l.message( "An error has occurred.", Logger.ERR );
    }
}

一、State模式定义:

　　允许一个对象在其状态改变时，改变它的行为。看起来对象似乎修改了它的类。

　　二、模式解说

　　State模式主要解决的是在开发中时常遇到的根据不同的状态需要进行不同的处理操作的问题,而这样的问题,大部分人是采用switch-case语句进行处理的,这样会造成一个问题:分支过多,而且如果加入一个新的状态就需要对原来的代码进行编译。State模式采用了对这些不同的状态进行封装的方式处理这类问题,当状态改变的时候进行处理然后再切换到另一种状态,也就是说把状态的切换责任交给了具体的状态类去负责.同时,State模式和 Strategy模式有很多相似的地方,需要说明的是两者的思想都是一致的,只不过封装的东西不同:State模式封装的是不同的状态,而Stategy 模式封装的是不同的算法。

　　三、结构图

　　State模式结构图如下:

　　四、怎么使用？

　　1）定义一个State接口，接口中有一个统一的方法，用以封装一个特定状态所对应的行为。

　　2）定义具体不同状态类ConcreteSate实现State接口。

　　3）每一个状态类都实现环境（Context）一个状态所对应的行为。

　　4）定义一个状态管理器Context.

　　五、一个例子

   1: interface State{

   2: public void handle(Context ctx);

   3: }

   4: class ConcreteStateA implements State{

   5: 　　

   6: public void handle(Context ctx) {

   7: 　System.out.println("handle by ConcreteStateA");

   8: 　if(ctx!=null){

   9: 　ctx.ChangeState(new ConcreteStateB());

  10: 　}

  11: 　

  12: }

  13: }

  14: class ConcreteStateB implements State{

  15: 　　

  16: public void handle(Context ctx) {

  17: 　System.out.println("handle by ConcreteStateB");

  18: 　if(ctx!=null){

  19: 　ctx.ChangeState(new ConcreteStateA());

  20: 　}

  21: 　

  22: }

  23: }

  24: class Context{

  25: private State _state;

  26: public Context(State state){

  27: 　_state=state;

  28: }

  29: public void request(){

  30: 　if(_state!=null){

  31: 　_state.handle(this);

  32: 　}

  33: }

  34: public void ChangeState(State s){

  35: 　if(_state!=null){

  36: 　_state=null;

  37: 　}

  38: 　_state=s;

  39: }

  40: }

  41: public class StateClient {

  42: 　　

  43: public static void main(String[] args) {

  44: 　State state=new ConcreteStateA();

  45: 　Context context=new Context(state);

  46: 　context.request();

  47: 　context.request();

  48: 　context.request();

  49: 　context.request();

  50: 　　

  51: }

  52: 　　

  53: }

输出结果:

　　handle by ConcreteStateA

　　handle by ConcreteStateB

　　handle by ConcreteStateA

　　handle by ConcreteStateB

　　每请求一次，状态就更换一次，就执行对应的行为。

　　六、适用性

　　1）一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为。

　　2）一个对象含有庞大的条件分支语句，这些分支依赖于它的状态。这个状态通常用一个或多个枚举常量表示。通常有多个操作包含这一相同的结构。State 模式将每一个分支放入一个独立的类中。这使得你可以根据对象自身的情况将对象的状态作为一个对象，这一对象可以不依赖于其他对象而独立变化。

　　七、优缺点

　　1)优点: 避免了为判断状态而产生的巨大的if或case语句。 将对象行为交给状态类维护后，对于上层程序而言，仅需要维护状态之间的转换规则。

　　2)会导致某些系统有过多的具体状态类。

　　八、参考

　　http://www.cppblog.com/converse/archive/2006/08/07/10902.html

　　http://www.blogjava.net/flying/archive/2006/08/29/66472.html

   1: import java.util.ArrayList;

   2:  

   3: abstract class AbstractMediator{

   4:  public abstract void register(AbstractColleague ac);

   5:  public abstract void ColleagueChanged(AbstractColleague ac);

   6: }

   7: abstract class AbstractColleague{

   8:  private AbstractMediator med;

   9:  public AbstractColleague(AbstractMediator mediator){

  10:   this.med=mediator;

  11:  }

  12:  public abstract void action();

  13:  public void changed(){

  14:   med.ColleagueChanged(this);

  15:  }

  16: }

  17: class ConcreteMediator extends AbstractMediator{

  18:  

  19:  private ArrayList<AbstractColleague> colleagueList=new ArrayList<AbstractColleague>();

  20:  public void register(AbstractColleague ac) {

  21:   colleagueList.add(ac); 

  22:  }

  23:  

  24:  public void ColleagueChanged(AbstractColleague ac) {

  25:   for(int i=0;i<colleagueList.size();i++){

  26:    if(colleagueList.get(i)!=ac){

  27:     colleagueList.get(i).action();

  28:    }

  29:   }

  30:  }

  31: }

  32:  

  33: class ConcreteColleagueA extends AbstractColleague{

  34:     public ConcreteColleagueA(AbstractMediator mediator){

  35:      super(mediator);

  36:      mediator.register(this);

  37:     }

  38:  public void action() {

  39:   System.out.println("AAAAAAAAAAAAAAA");

  40:  }

  41: }

  42: class ConcreteColleagueC extends AbstractColleague{

  43:     public ConcreteColleagueC(AbstractMediator mediator){

  44:      super(mediator);

  45:      mediator.register(this);

  46:     }

  47:  public void action() {

  48:   System.out.println("CCCCCCCCCCCCCCC");

  49:  }

  50: }

  51: class ConcreteColleagueB extends AbstractColleague{

  52:   public ConcreteColleagueB(AbstractMediator mediator){

  53:       super(mediator);

  54:       mediator.register(this);

  55:      }

  56:   public void action() {

  57:    System.out.println("BBBBBBBBBBBBBBB");

  58:   }

  59: }

  60: class test{

  61:  public static void main(String[] args){

  62:  AbstractMediator mediator=new ConcreteMediator();

  63:  AbstractColleague colleagueA=new ConcreteColleagueA(mediator);

  64:  AbstractColleague colleagueB=new ConcreteColleagueB(mediator);

  65:  AbstractColleague colleagueC=new ConcreteColleagueC(mediator);

  66:  colleagueA.changed();

  67:  colleagueB.changed();

  68:  colleagueC.changed();

  69:  }

  70: }

  71:  

五、 优缺点
1）减少了子类生成Mediator将原本分布于多个对象间的行为集中在一起，改变这些行为只需生成Mediator的子类即可，这样各个Colleague类可被重用。
2）它将各Colleague解耦。Mediator有利于各Colleague间的松耦合，你可以独立的改变和复用各Colleague类和Mediator类。
3）它简化了对象协议用Mediator和各Colleague间的一对多的交互来代替多对多的交互。一对多的关系更易于理解、维护和扩展。
4）它对对象如何协作进行了抽象将中介作为一个独立的概念并将其封装在一个对象中，使你将注意力从对象各自本身的行为转移到它们之间的交互上来。这有助于弄清楚一个系统中的对象是如何交互的。
5）它使控制集中化，中介者模式将交互的复杂性变为中介者的复杂性。因为中介者封装了协议，它可能变得比任一个Colleague都复杂。这可能使得中介者自身成为一个难于维护的庞然大物。
六、 适用性
1）一组对象以定义良好但是复杂的方式进行通信。产生的相互依赖关系结构混乱且难以理解。
2）一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象。

interface DrawingAPI {

    public void drawCircle(double x, double y, double radius);

}

/** "ConcreteImplementor" 1/2 */

class DrawingAPI1 implements DrawingAPI {

   public void drawCircle(double x, double y, double radius) {

        System.out.printf("API1.circle at %f:%f radius %f\n", x, y, radius);

   }

}

/** "ConcreteImplementor" 2/2 */

class DrawingAPI2 implements DrawingAPI {

   public void drawCircle(double x, double y, double radius) { 

        System.out.printf("API2.circle at %f:%f radius %f\n", x, y, radius);

   }

}

/** "Abstraction" */

interface Shape {

   public void draw();                                            // low-level

   public void resizeByPercentage(double pct);     // high-level

}

/** "Refined Abstraction" */

class CircleShape implements Shape {

   private double x, y, radius;

   private DrawingAPI drawingAPI;

   public CircleShape(double x, double y, double radius, DrawingAPI drawingAPI) {

       this.x = x;  this.y = y;  this.radius = radius; 

       this.drawingAPI = drawingAPI;

   }

   // low-level i.e. Implementation specific

   public void draw() {

        drawingAPI.drawCircle(x, y, radius);

   }   

   // high-level i.e. Abstraction specific

   public void resizeByPercentage(double pct) {

        radius *= pct;

   }

}

/** "Client" */

class BridgePattern {

   public static void main(String[] args) {

       Shape[] shapes = new Shape[2];

       shapes[0] = new CircleShape(1, 2, 3, new DrawingAPI1());

       shapes[1] = new CircleShape(5, 7, 11, new DrawingAPI2());

       for (Shape shape : shapes) {

           shape.resizeByPercentage(2.5);

           shape.draw();

       }

   }

}

Bridge遵循的是接口隔离原则的典型。比如，随着时代的发展，枪在不停的变化改进。与此同时枪的子弹也在改进，很多子弹赋予了新功能：比如信号弹，救援弹，甚至是炸弹。这样，枪是抽象的同时，子弹也是抽象的。二者组合起来变换无穷。仔细想一下《java与模式》中桥梁模式的例子--飞机和飞机制造商是不是也是这种灵活变换的组合？