对几种常见设计模式的理解

对几种常见设计模式的理解

　　设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

　　最早提出“设计模式”概念的是建筑设计大师亚力山大Alexander。在1970年他的《建筑的永恒之道》里描述了投计模式的发现，因为它已经存在了千百年之久，而现代才被通过大量的研究而被发现。在《建筑的永恒之道》里这样描述：模式是一条由三个部分组成的通用规则：它表示了一个特定环境、一类问题和一个解决方案之间的关系。每一个模式描述了一个不断重复发生的问题，以及该问题解决方案的核心设计。

一、23种经典的设计模式

　　 

二、设计模式的六大原则

1、开闭原则 
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类。 
2、里氏代换原则 
里氏代换原则面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。 
3、依赖倒转原则 
这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。 
4、接口隔离原则 
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。 
5、迪米特法则（最少知道原则） 
为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。 
6、合成复用原则 
原则是尽量使用合成/聚合的方式，而不是使用继承。

三、为什么要把很简单的东西搞得那么复杂

　　我们所理解的“简单”就是一把钥匙开一把锁的模式，目的仅仅是着眼于解决现在的问题，而设计模式的“复杂”就在于它是要构造一个“万能钥匙”，目的是提出一种对所有锁的开锁方案。在真正理解设计模式之前我一直在编写“简单”的代码。这个“简单”不是功能的简单，而是设计的简单。简单的设计意味着缺少灵活性，代码很钢硬，只在这个项目里有用，拿到其它的项目中就是垃圾，我将其称之为“一次性代码”。

下面的一个例子说明了“为什么要把很简单的东西搞得那么复杂”：（策略模式）

说明： 
模拟鸭子游戏的应用程序，要求：游戏中会出现各种颜色外形的鸭子，一边游泳戏水，一边呱呱叫。

第一种方法：（一次性代码） 
直接编写出各种鸭子的类：MallardDuck//野鸭，RedheadDuck//红头鸭，各类有三个方法：

quack()：叫的方法
swim()：游水的方法
display()：外形的方法

• 1
• 2
• 3

第二种方法：运用继承的特性，将其中共同的部分提升出来，避免重复编程。 
即：设计一个鸭子的超类（Superclass）,并让各种鸭子继承这个超类。

public class Duck{
     public void quack(){  //呱呱叫
              System.out.println("呱呱叫");
      }
     public void swim(){   //游泳
            System.out.println(" 游泳");
      }    
     public  abstratact void display(); /*因为外观不一样，让子类自己去决定了。*/
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

对于它的子类只需简单的继承就可以了，并实现自己的display()方法。

//野鸭
 public class MallardDuck extends Duck{
     public void display(){
          System.out.println("野鸭的颜色...");
   }
 }
//红头鸭
 public class RedheadDuck extends Duck{
     public void display(){
          System.out.println("红头鸭的颜色...");
   }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

不幸的是，现在客户又提出了新的需求，想让鸭子飞起来。这个对于程序员，在简单不过了，在超类中在加一个方法就可以了。

public class Duck{
     public void quack(){  //呱呱叫
              System.out.println("呱呱叫");
      }
     public void swim(){   //游泳
            System.out.println(" 游泳");
    }    
    public  abstract void display(); /*因为外观不一样，让子类自己去决定了。*/
   public void fly(){
        System.out.println("飞吧！鸭子"); 
  }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12

这样所有的继承这个超类的鸭子都会fly了。但是问题又出来了，客户又提出有的鸭子会飞，有的不能飞对于不能飞的鸭子，在子类中只需简单的覆盖。

//残废鸭
 public class DisabledDuck extends Duck{
     public void display(){
          System.out.println("残废鸭的颜色...");
   }
   public void fly(){
    //覆盖，变成什么事都不做。 
  }
} 

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

其它会飞的鸭子不用覆盖。

点评: 
对于上面的设计，你可能发现一些弊端，如果超类有新的特性，子类都必须变动，这是我们开发最不喜欢看到的，一个类变让另一个类也跟着变，这有点不符合OO设计了。这样很显然的耦合了一起。利用继承–>耦合度太高了.

第三种方法：用接口改进. 
我们把容易引起变化的部分提取出来并封装之，来应付以后的变法。虽然代码量加大了，但可用性提高了，耦合度也降低了。 
我们把Duck中的fly方法和quack提取出来。

    public interface Flyable{
      public void fly(); 
  }
   public interface Quackable{
     public void quack();
  }

• 1
• 2
• 3
• 4
• 5
• 6

最后Duck的设计成为：

public class Duck{
     public void swim(){   //游泳
            System.out.println(" 游泳");
    }    
    public  abstract void display(); /*因为外观不一样，让子类自 己去决定了。*/
}

• 1
• 2
• 3
• 4
• 5
• 6

而MallardDuck,RedheadDuck,DisabledDuck 就可以写成为：

//野鸭
 public class MallardDuck extends Duck  implements Flyable,Quackable{
     public void display(){
          System.out.println("野鸭的颜色...");
   }
   public void fly(){
    //实现该方法
  }
   public void quack(){
    //实现该方法
  }
 }
//红头鸭
 public class RedheadDuck extends Duck implements Flyable,Quackable{
     public void display(){
          System.out.println("红头鸭的颜色...");
   }
   public void fly(){
    //实现该方法
  }
   public void quack(){
    //实现该方法
  }
} 
//残废鸭 只实现Quackable（能叫不能飞）
 public class DisabledDuck extends Duck implements Quackable{
     public void display(){
          System.out.println("残废鸭的颜色...");
   }
   public void quack(){
    //实现该方法
  }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33

点评: 
好处: 
这样已设计，我们的程序就降低了它们之间的耦合。 
不足: 
Flyable和 Quackable接口一开始似乎还挺不错的，解决了问题（只有会飞到鸭子才实现 Flyable），但是Java接口不具有实现代码，所以实现接口无法达到代码的复用。

第四种方法：可用以下的策略模式来解决.

————————- strategy(策略模式) ————————-

我们有一个设计原则： 
找出应用中相同之处，且不容易发生变化的东西，把它们抽取到抽象类中，让子类去继承它们；找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。 
–>important.现在，为了要分开“变化和不变化的部分”，我们准备建立两组类（完全远离Duck类），一个是”fly”相关的，另一个是“quack”相关的，每一组类将实现各自的动作。比方说，我们可能有一个类实现“呱呱叫”，另一个类实现“吱吱叫”，还有一个类实现“安静”。

首先写两个接口。FlyBehavior(飞行行为)和QuackBehavior（叫的行为）.

 public interface FlyBehavior{
     public void fly();     
 }
 public interface QuackBehavior{
     public void quack();
 }

• 1
• 2
• 3
• 4
• 5
• 6

我们在定义一些针对FlyBehavior的具体实现。

public class FlyWithWings implements FlyBehavior{
    public void  fly(){
     //实现了所有有翅膀的鸭子飞行行为。
   }
 }
public class FlyNoWay implements FlyBehavior{

    public void  fly(){
      //什么都不做，不会飞
    }
 }   

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11

针对QuackBehavior的几种具体实现。

public class Quack implements QuackBehavior{
    public void quack(){
      //实现呱呱叫的鸭子
  }
}

public class Squeak implements QuackBehavior{
    public void quack(){
      //实现吱吱叫的鸭子 
  }
}

public class MuteQuack implements QuackBehavior{
    public void quack(){
      //什么都不做，不会叫
  }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17

点评一: 
这样的设计，可以让飞行和呱呱叫的动作被其他的对象复用，因为这些行为已经与鸭子类无关了。而我们增加一些新的行为，不会影响到既有的行为类，也不会影响“使用”到飞行行为的鸭子类。

最后我们看看Duck 如何设计。

   public class Duck{        --------->在抽象类中,声明各接口,定义各接口对应的方法.
      FlyBehavior flyBehavior;//接口
      QuackBehavior quackBehavior;//接口
       public Duck(){}
       public abstract void display();
       public void swim(){
        //实现游泳的行为
        }
       public void performFly(){
            flyBehavior.fly();  -->由于是接口,会根据继承类实现的方式,而调用相应的方法.
         }
     public void performQuack(){
          quackBehavior.quack();
        }
 }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15

看看MallardDuck如何实现。 
—–>通过构造方法,生成’飞’,’叫’具体实现类的实例,从而指定’飞’,’叫’的具体属性

public class MallardDuck extends Duck{
       public MallardDuck {       
        flyBehavior = new FlyWithWings ();
        quackBehavior = new Quack(); 
      //因为MallardDuck 继承了Duck，所有具有flyBehavior 与quackBehavior 实例变量
      }
    public void display(){
     //实现
   }
 }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

这样就满足了即可以飞，又可以叫，同时展现自己的颜色了。 
这样的设计我们可以看到是把flyBehavior ，quackBehavior 的实例化写在子类了。我们还可以动态的来决定。 
我们只需在Duck中加上两个方法。

在构造方法中对属性进行赋值与用属性的setter的区别： 
构造方法中对属性进行赋值：固定，不可变； 
用属性的setter，可以在实例化对象后，动态的变化，比较灵活。

  public class Duck{
      FlyBehavior flyBehavior;//接口
      QuackBehavior quackBehavior;//接口
      public void setFlyBehavior(FlyBehavior flyBehavior){
            this.flyBehavior = flyBehavior;
     }
    public void setQuackBehavior(QuackBehavior quackBehavior  {
            this.quackBehavior= quackBehavior;
     }
 }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10

四、几种常见的设计模式

1、单例模式(singelton)

基本概念: 
Singleton 是一种创建性模型,它用来确保只产生一个实例,并提供一个访问它的全局访问点.对一些类来说,保证只有一个实例是很重要的,比如有的时候,数据库连接或 Socket 连接要受到一定的限制,必须保持同一时间只能有一个连接的存在. 
运用： 
在于使用static变量； 
创建类对象，一般是在构造方法中，或用一个方法来创建类对象。在这里方法中，加对相应的判断即可。

public class Singleton {  
  private static Singleton s; 
  public static Singleton getInstance() {
    if (s == null)
      s = new Singleton();
    return s;
  }
}
// 测试类
class singletonTest {
  public static void main(String[] args) {
    Singleton s1 = Singleton.getInstance();
    Singleton s2 = Singleton.getInstance();
    if (s1==s2)
      System.out.println("s1 is the same instance with s2");
    else
      System.out.println("s1 is not the same instance with s2");
  }
}
singletonTest运行结果是:
s1 is the same instance with s2

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21

2、简单工厂(StaticFactory Method)

　　简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。 
　　举例如下：（我们举一个发送邮件和短信的例子） 
首先，创建二者的共同接口：

[java] view plaincopy
public interface Sender {  
    public void Send();  
}  

• 1
• 2
• 3
• 4

其次，创建实现类：

[java] view plaincopy
public class MailSender implements Sender {  
    @Override  
    public void Send() {  
        System.out.println("this is mailsender!");  
    }  
}  
[java] view plaincopy
public class SmsSender implements Sender {  

    @Override  
    public void Send() {  
        System.out.println("this is sms sender!");  
    }  
}  

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15

最后，建工厂类：

[java] view plaincopy
public class SendFactory {  

    public Sender produce(String type) {  
        if ("mail".equals(type)) {  
            return new MailSender();  
        } else if ("sms".equals(type)) {  
            return new SmsSender();  
        } else {  
            System.out.println("请输入正确的类型!");  
            return null;  
        }  
    }  
}  

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14

我们来测试下：

[java] view plaincopy
public class FactoryTest {  

    public static void main(String[] args) {  
        SendFactory factory = new SendFactory();  
        Sender sender = factory.produce("sms");  
        sender.Send();  
    }  
}  

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9

输出：this is sms sender!

3、观察者模式(Observer)

基本概念: 
　　观察者模式属于行为型模式，其意图是定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这一个模式的关键对象是目标（Subject）和观察者（Observer）。一个目标可以有任意数目的依赖它的观察者，一旦目标的状态发生改变，所有的观察者都得到通知，作为对这个通知的响应，每个观察者都将查询目标以使其状态与目标的状态同步。 
适用场景： 
　　观察者模式，用于存在一对多依赖关系的对象间，当被依赖者变化时，通知依赖者全部进行更新。因此，被依赖者，应该有添加/删除依赖者的方法，且可以将添加的依赖者放到一个容器中；且有一个方法去通知依赖者进行更新。

4、迭代器模式(Iterator)

基本概念: 
迭代器模式属于行为型模式，其意图是提供一种方法顺序访问一个聚合对象中得各个元素，而又不需要暴露该对象的内部表示。至少可以历遍first,next,previous,last,isOver,或是历遍选择符合某种条件的子元素.

5、外观模式(Facade)

　　外观模式属于结构型模式，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。外观模式的主要用途就是为子系统的复杂处理过程提供方便的调用方法，使得子系统更加容易被使用。–>将复杂的过程包含在里面,提供一个简单的应用接口即可.

例如在一个泡茶的过程中，需要作如下的工作：烧开水，准备茶叶，把茶叶放在被子里，把烧开的水放到茶杯中，只有经过这些过程之后才能泡出好的茶叶来。这是一个常用的步骤，80%的泡茶步骤都是这个样子的，可以把这些动作串联起来，形成一个整体的步骤.如下例的MakeACuppa()，使用了facade的模式,这样在调用步方法时就比较方便。这便是外观模式，里面的细节被屏蔽掉了。

public class TeaCup{.....}
public class TeaBag{.....}
public class Water{.....}
public class FacadeCuppaMaker{
    private boolean TeaBagIsSteeped;
    public FacadeCuppaMaker(){
       System.out.println("FacadeCuppaMaker 准备好冲茶了");
    }
    public TeaCup makeACuppa(){
       TeaCup cup = new TeaCup();
       TeaBag teaBag= new TeaBag();
       Water water = new Water();
       cup.addFacadeTeaBag(teaBag);
       water.boilFacadeWater();
       cup.addFacadeWater(water);
       cup.steepTeaBag();
       return cup;
    }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19

6、适配器模式(adapter)

适配器模式的意图是将一个已存在的类/接口进行复用,将其转换/具体化成客户希望的另外的一个类/接口。 
如何实例复用： 
将要进行复用的类，放到目标类的构造方法中，进行实例化，然后在目标类的相应方法中，进行调用，修改原来方法中的参数，或添加相应的逻辑。即复用了已有类的原来方法。 
要被复用的类：

public class Adaptee{
    public long getPower(long base,long exp){
       long result=1;
       for(int i=0;i<exp;i++)
           result*=base;
       return result;
    }
}
目标类：--也可直接实现，不用接口。
public interface Target{
    public long get2Power(long exp);
}
public class Adapter implements Target{
    private Adaptee pt;
    public Adapter(){
       pt = new Adaptee();
    }
    public long get2Power(long exp){
       return pt.getPower(2,exp);   ---修改原来方法中的参数，
    }
}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21

7、建造模式（Builder）

　　建造模式：将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示.Builder模式是一步一步创建一个复杂的对象,它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们.用户不知道内部的具体构建细节.Builder模式是非常类似抽象工厂模式,细微的区别大概只有在反复使用中才能体会到。 
将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。

8、合成模式（Composite）

　　合成模式：将对象以树形结构组织起来,以达成“部分－整体” 的层次结构，使得客户端对单个对象和组合对象的使用具有一致性. 合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。 
windows的目录树（文件系统）

9、状态模式（State）

　　状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状态类的子类。当系统的状态变化时，系统便改变所选的子类。

另外，MVC模式

　　MVC模式：它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。相互通信。MVC还使用了的设计模式，如：用来指定视图缺省控制器的Factory Method和用来增加视图滚动的Decorator。但是MVC的主要关系还是由Observer、Composite和Strategy三个设计模式给出的。