23种设计模式之几种常用模式

设计模式的6大原则：                                         源
1、单一职责原则 -----每个类应该实现单一的职责
2、里氏替换原则------继承复用，增加新的行为
3、依赖倒转原则------依赖抽象而不依赖具体
4、接口隔离原则------使用多个隔离的接口
5、迪米特法则--------只与直接的朋友通信，减少依赖
6、合成复用原则------使用合成/聚合的方式，而不是使用继承

创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式

结构型模式，共七种：适配器模式、装饰者模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
 

代理模式
 

代理模式的定义：
代理是设计模式的一种，代理类为委托类提供消息预处理，消息转发，事后消息处理等功能。
Java中的代理按照代理类生成时机不同又分为静态代理和动态代理，代理分为三种角色：

1、代理类(ProxySubject)
2、委托类(RealSubject)
3、接口(Subject)

静态代理
静态代理代理类在编译期就生成，而动态代理代理类则是在Java运行时动态生成，静态代理代码冗余大，一但需要修改接口，代理类和委托类都需要修改。

举个例子
接口(Subject)：

interface HelloService {
    void sayHello();
}

委托类：

class HelloServiceImpl implements HelloService {
    @Override
    public void sayHello() {
        System.out.println("Hello World!");
    }
}

代理类：

class HelloServiceProxy implements HelloService {
    private HelloService helloService;
    
    public HelloServiceProxy(HelloService helloService) {
        this.helloService = helloService;
    }
    
    @Override
    public void sayHello() {
        System.out.println("Before say hello...");
        helloService.sayHello();
        System.out.println("After say hello...");
    }
}

测试类：

public class HelloServiceProxyTest {
    public static void main(String[] args) {
        HelloService helloService = new HelloServiceImpl();
        HelloServiceProxy proxy = new HelloServiceProxy(helloService);
        proxy.sayHello();
    }
}

输出结果：
Before say hello...
Hello World!
After say hello...


 

动态代理
Java中的动态代理代理类在JVM运行时动态生成，依靠反射来实现，委托类需要实现接口。
Java动态代理主要涉及到两个类：java.lang.reflect.Proxy和java.lang.reflect.InvocationHandler。代理类需要实现InvocationHandler接口或者创建匿名内部类。

接口(Subject)：

interface HelloService {
    void sayHello();
}

委托类：

class HelloServiceImpl implements HelloService {
    @Override
    public void sayHello() {
        System.out.println("Hello World!");
    }
}

动态代理类：

class HelloServiceDynamicProxy {
    private HelloService helloService;
    public HelloServiceDynamicProxy(HelloService helloService) {
        this.helloService = helloService;
    }
    public Object getProxyInstance() {
        return Proxy.newProxyInstance(helloService.getClass().getClassLoader(), helloService.getClass().getInterfaces(), new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                System.out.println("Before say hello...");
                Object ret = method.invoke(helloService, args);
                System.out.println("After say hello...");
                return ret;
            }
        });
    }
}

测试类：

public class HelloServieDynamicProxyTest {
    public static void main(String[] args){
        HelloService helloService = new HelloServiceImpl();
        HelloService dynamicProxy = (HelloService) new HelloServiceDynamicProxy(helloService).getProxyInstance();
        dynamicProxy.sayHello();
    }
}

输出结果
Before say hello...
Hello World!
After say hello...

 

单例

//饿汉式 类一加载进内存就创建好了对象
class Singleton {  
    private Singleton() {} 
    private static Singleton s = new Singleton(); 
    public static Singleton getInstance() {  
         return s; 
        } 
      }  

懒汉式是类加载进内存的时候，对象还没有存在，要使用该对象的时候再new出来，*懒汉式是延迟加载，如果多个线程同时操作懒汉式时就有可能出现线程安全问题 为解决饱汉式的线程安全问题，解决线程安全问题可以加同步来解决。但是加了同步之后，每一次都要比较锁，效率就变慢了。

//懒汉式 
class Single { 
    private Single() {} 
    private static Single s = null ;  
    public static Single getInstance() { 
    public static synchronized Single getInstance() {    //加锁同步安全
        if (s == null) {  
          s = new Single();    
        }         
      return s;   
} }  

通过双重判断来提高程序效率，所谓“双重检查加锁”机制，指的是：

//双重检查
class Single { 
    private Single() {} 
    private volatile static Single s = null;  
    public static Single getInstance() {
       //先检查实例是否存在，如果不存在才进入下面的同步块
        if (s == null) {  
            //同步快，线程安全创建实例
           synchronized (Singleton.class) {
             //再次检查实例是否存在，如果不存在才真正的创建实例
                if(s == null){
                     s = new Single();    
                }
              }
        }         
      return s;   
} }

1、第一个条件是说，如果实例创建了，那就不需要同步了，直接返回就好了。  if (singleton== null)  {
2、不然，我们就开始同步线程。                               synchronized (Singleton.class) {
3、第二个条件是说，如果被同步的线程中有一个线程创建了对象，那么别的线程就不用再创建了。  if (singleton== null)  {

问题主要在于singleton = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情
1、给 singleton 分配内存
2、调用 Singleton 的构造函数来初始化成员变量，形成实例
3、将singleton对象指向分配的内存空间（执行完这步 singleton才是非 null 了）

但是在 JVM 的即时编译器中存在指令重排序的优化。也就是说上面的第二步和第三步的顺序是不能保证的，最终的执行顺序可能是 1-2-3 也可能是 1-3-2。如果是后者，则在 3 执行完毕、2 未执行之前，被线程二抢占了，这时 instance 已经是非 null 了（但却没有初始化），所以线程二会直接返回 instance，然后使用，然后顺理成章地报错

对此，我们只需要把singleton声明成 volatile 就可以了，有两个功用：

1）这个变量不会在多个线程中存在复本，所有对该变量的读写都是直接操作共享内存，从而确保多个线程能正确的处理该变量

2）这个关键字会禁止指令重排序优化。也就是说，在 volatile 变量的赋值操作后面会有一个内存屏障（生成的汇编代码上），读操作不会被重排序到内存屏障之前。

静态内部类：

支持多线程-懒汉式
//特点：利用静态内部类（只有在出现它的引用时才被加载），完成懒加载
 
class Single{
    private Single(){}
    public static Single getInstance(){
        return SingleHolder.instance;
    }
    private static class SingleHolder{
        public static Single instance = new Single();
    }
}

观察者模式

/**
 * 抽象观察者类
 */
public interface IObserver {
    void update(String message);
}

/**
 * 抽象主题类
 */
public interface ISubject {
    void add(IObserver observer);
    void remove(IObserver observer);
    void notify(String message);
}

/**
 * 具体观察者类
 */
public class Observer implements IObserver {
    @Override
    public void update(String message) {
        System.out.println(message);
    }
}

/**
 * 具体主题类
 */
public class Subject implements ISubject {
    List<IObserver> list = new ArrayList<>();

    @Override
    public void add(IObserver observer) {
        list.add(observer);
    }

    @Override
    public void remove(IObserver observer) {
        list.remove(observer);
    }

    @Override
    public void notify(String message) {
        for(IObserver observer: list){
            observer.update(message);
        }
    }
}

模式分析

抛去模式中的接口类，就剩下了主题和观察者，这个模式的发生就是基于主题的变更与对观察者的通知。

这个模式在我的 helper 工具包中也有使用，就是基于对系统服务的监听，发现变化后，对订阅此变化的观察者们发出通知，并由观察者自己作出相应的动作。

缺点：

1. 一个主题存在多个观察者，而通知的方式是通过轮询，这样的通知会有一定的时间消耗。
2. 如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。

 

适配器模式

类适配器

public interface MP4{
    void play();
}

public class MP4Player implements MP4{
    public void play(){
        // doSomething
    }
}

public interface Player{
      void action();
}

public class Adapter extends MP4Player implements Player{
    public void action(){
        play();
    }
}

对象适配器

public class PlayerAdapter implements Player{
    public MP4 mp4;
    
    public PlayerAdapter (MP4 mp4){
        this.mp4 = mp4;
    }     

    public void action(){
        if(mp4!= null){
             mp4.play();
        }
    }
}

模式分析

适配器模式简单来说就是为两个互不兼容的两者提供了合作的桥梁。

想一想我们在Android中使用的RecyclerView中为了进行数据的适配是不是都会加上一个Adapter，因为我们从网络获取的数据Bean是无法直接和XML文件中的每个View需要填充的数据项进行对应的。而适配器就是将两者进行了沟通协作。

类适配器模式和对象适配器模式的区别是什么？

类适配器使用了继承的方式来完成、对象适配器使用了依赖的关系来完成任务。拿代码来说的话就是类适配器继承了MP4Player，而对象适配器依赖就是MP4这个接口类的使用。

缺点

• 类适配器模式 对于Java、C#等不支持多重继承的语言，一次最多只能适配一个适配者类，而且目标抽象类只能为抽象类，不能为具体类，其使用有一定的局限性，不能将一个适配者类和它的子类都适配到目标接口。
• 对象适配器模式 与类适配器模式相比，要想置换适配者类的方法就不容易。如果一定要置换掉适配者类的一个或多个方法，就只好先做一个适配者类的子类，将适配者类的方法置换掉，然后再把适配者类的子类当做真正的适配者进行适配，实现过程较为复杂。

策略模式

方案
把一个类中经常改变或者将来可能改变的部分提取出来，作为一个接口，然后在类中包含这个对象的实例，这样类的实例在运行时就可以随意调用实现了这个接口的类的行为。

适用情况
许多相关的类仅仅是行为有异。 “策略”提供了一种用多个行为中的一个行为来配置一个类的方法。即一个系统需要动态地在几种算法中选择一种。

优点
1、可以动态的改变对象的行为
缺点
1、客户端必须知道所有的策略类，并自行决定使用哪一个策略类
2、策略模式将造成产生很多策略类

组成
抽象策略类(Strategy):定义所有支持的算法的公共接口
具体策略类(ConcreteStrategy):以Strategy接口实现某具体算法。
环境类(Context): 使用这个接口来调用某ConcreteStrategy定义的算法，通过Context来连接起Strategy和ConcreteStrategy桥梁。

举个栗子：
场景如下，刘备要到江东娶老婆了，走之前诸葛亮给赵云三个锦囊妙计，说是按天机拆开能解决棘手问题。场景中出现三个要素：三个妙计（具体策略类）、一个锦囊（环境类）、赵云（调用者）

抽象策略类（Strategy）

public interface Strategy {
     public void operate();
}

三个实现类（ConcreteStrategy）

妙计一：初到吴国

public class IntoCountry implements Strategy {
     @Override
     public void operate() {
          System.out.println("找乔国老帮忙，让吴国太给孙权施加压力，使孙权不能杀刘备");
     }
}

妙计二：求吴国太开绿灯放行

public class GivenGreenLight implements Strategy {
     @Override
     public void operate() {
          System.out.println("求吴国太开个绿灯，放行");
     }
}

妙计三：孙夫人断后，挡住追兵

public class BlockEnemy implements Strategy {
     @Override
     public void operate() {
          System.out.println("孙夫人断后，挡住追兵");
     }
}

环境类（Context)

public class Context {
     private Strategy strategy;
     //构造函数，要你使用哪个妙计
     public Context(Strategy strategy){
          this.strategy = strategy;
     }
     public void operate(){
          this.strategy.operate();
     }
}

下面就是使用的情况了

public class Zhaoyun {
 
public static void main(String[] args) {
     System.out.println("----------刚到吴国使用第一个锦囊---------------");
     Context IntoCountry = new Context(new IntoCountry());
     IntoCountry.operate();
 
     System.out.println("----------刘备乐不思蜀使用第二个锦囊---------------");
     Context GivenGreenLight = new Context(new GivenGreenLight());
     GivenGreenLight.operate();
   
     System.out.println("----------孙权的追兵来了，使用第三个锦囊---------------");
     Context BlockEnemy = new Context(new BlockEnemy());
     BlockEnemy.operate();
     }
}

以上就是策略模式，多种不同解决方案动态切换，起到改变对象行为的效果。

 

建造者模式（Builder Pattern）

UML类图 & 组成

 

模式讲解：

1、指挥者（Director）直接和客户（Client）进行需求沟通；
2、沟通后指挥者将客户创建产品的需求划分为各个部件的建造请求（Builder）；
3、将各个部件的建造请求委派到具体的建造者（ConcreteBuilder）；
4、各个具体建造者负责进行产品部件的构建；
5、最终构建成具体产品（Product）

举个栗子：小成希望去电脑城买一台组装的台式主机
过程：
1、电脑城老板（Diretor）和小成（Client）进行需求沟通（买来打游戏？学习？看片？）
2、了解需求后，电脑城老板将小成需要的主机划分为各个部件（Builder）的建造请求（CPU、主板blabla）
3、指挥装机人员（ConcreteBuilder）去构建组件；
4、将组件组装起来成小成需要的电脑（Product）

使用步骤
步骤1： 定义组装的过程（Builder）：组装电脑的过程

public  abstract class Builder {  

//第一步：装CPU
//声明为抽象方法，具体由子类实现 
    public abstract void  BuildCPU()；

//第二步：装主板
//声明为抽象方法，具体由子类实现 
    public abstract void BuildMainboard（）；

//第三步：装硬盘
//声明为抽象方法，具体由子类实现 
    public abstract void BuildHD（）；

//返回产品的方法：获得组装好的电脑
    public abstract Computer GetComputer（）；
}

步骤2： 电脑城老板委派任务给装机人员（Director）

public class Director{
       //指挥装机人员组装电脑
       public void Construct(Builder builder){
         builder. BuildCPU();
         builder.BuildMainboard（）;
         builder. BuildHD（）;
        }
 }

步骤3：创建具体的建造者（ConcreteBuilder）:装机人员

//装机人员1
  public class ConcreteBuilder extend  Builder{
    //创建产品实例
    Computer computer = new Computer();

    //组装产品
    @Override
    public void  BuildCPU(){  
       computer.Add("组装CPU")
    }  

    @Override
    public void  BuildMainboard（）{  
       computer.Add("组装主板")
    }  

    @Override
    public void  BuildHD（）{  
       computer.Add("组装主板")
    }  

    //返回组装成功的电脑
     @Override
      public  Computer GetComputer（）{  
      return computer
    }  
}

步骤4：定义具体产品类（Product）：电脑

public class Computer{
    
    //电脑组件的集合
    private List<String> parts = new ArrayList<String>()；
     
    //用于将组件组装到电脑里
    public void Add(String part){
    parts.add(part);
}
    
    public void Show(){
          for (int i = 0;i<parts.size();i++){    
          System.out.println(“组件”+parts.get(i)+“装好了”);
          }
          System.out.println(“电脑组装完成，请验收”); 
      }

}

步骤5：客户端调用-小成到电脑城找老板买电脑

public class Builder Pattern{
  public static void main(String[] args){

//逛了很久终于发现一家合适的电脑店
//找到该店的老板和装机人员
  Director director = new Director();
  Builder builder = new ConcreteBuilder();

//沟通需求后，老板叫装机人员去装电脑
director.Construct(builder);

//装完后，组装人员搬来组装好的电脑
Computer computer = builder.GetComputer();
//组装人员展示电脑给小成看
computer.Show()；

    }
        
}
   

结果输出

组件CUP装好了
组件主板装好了
组件硬盘装好了
电脑组装完成，请验收

 优点
1、易于解耦
将产品本身与产品创建过程进行解耦，得到不同的产品。也就说细节依赖抽象。

2、易于精确控制对象的创建
将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰

3、易于拓展
增加新的具体建造者无需修改原有类库的代码，易于拓展，符合“开闭原则“。
每一个具体建造者都相对独立，而与其他的具体建造者无关

 缺点
1、如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。
2、如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。

应用场景
1、需要生成的产品对象有复杂的内部结构，这些产品对象具备共性；
2、隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。