Java设计模式精讲

时间 2019-11-17

标签 java 设计模式栏目 Java 繁體版

原文原文链接

设计模式是对你们实际工做中写的各类代码进行高层次抽象的总结

设计模式分为 23 种经典的模式，根据用途咱们又能够分为三大类。分别是建立型模式、结构型模式和行为型模式
列举几种设计原则，这几种设计原则将贯通全文：
- 面向接口编程，而不是面向实现。这个尤其重要，也是优雅的、可扩展的代码的第一步，这就不须要多说了吧
- 职责单一原则。每一个类都应该只有一个单一的功能，而且该功能应该由这个类彻底封装起来
- 对修改关闭，对扩展开放。对修改关闭是说，咱们辛辛苦苦加班写出来的代码，该实现的功能和该修复的 bug 都完成了，别人可不能说改就改；对扩展开放就比较好理解了，也就是说在咱们写好的代码基础上，很容易实现扩展。

建立型模式

建立型模式的做用就是建立对象，new 一个对象，而后 set 相关属性。可是，在不少场景下，咱们须要给客户端提供更加友好的建立对象的方式，尤为是那种咱们定义了类，可是须要提供给其余开发者用的时候。

简单工厂模式

和名字同样简单，很是简单，直接上代码吧：

public class FoodFactory {

    public static Food makeFood(String name) {
        if (name.equals("noodle")) {
            Food noodle = new LanZhouNoodle();
            noodle.addSpicy("more");
            return noodle;
        } else if (name.equals("chicken")) {
            Food chicken = new HuangMenChicken();
            chicken.addCondiment("potato");
            return chicken;
        } else {
            return null;
        }
    }
}
复制代码

其中，LanZhouNoodle 和 HuangMenChicken 都继承自 Food。
简单地说，简单工厂模式一般就是这样，一个工厂类 XxxFactory，里面有一个静态方法，根据咱们不一样的参数，返回不一样的派生自同一个父类（或实现同一接口）的实例对象。

咱们强调职责单一原则，一个类只提供一种功能，FoodFactory 的功能就是只要负责生产各类 Food。java

工厂模式

简单工厂模式很简单，若是它能知足咱们的须要，我以为就不要折腾了。之因此须要引入工厂模式，是由于咱们每每须要使用两个或两个以上的工厂。

public interface FoodFactory {
    Food makeFood(String name);
}
public class ChineseFoodFactory implements FoodFactory {

    @Override
    public Food makeFood(String name) {
        if (name.equals("A")) {
            return new ChineseFoodA();
        } else if (name.equals("B")) {
            return new ChineseFoodB();
        } else {
            return null;
        }
    }
}
public class AmericanFoodFactory implements FoodFactory {

    @Override
    public Food makeFood(String name) {
        if (name.equals("A")) {
            return new AmericanFoodA();
        } else if (name.equals("B")) {
            return new AmericanFoodB();
        } else {
            return null;
        }
    }
}
复制代码

其中，ChineseFoodA、ChineseFoodB、AmericanFoodA、AmericanFoodB 都派生自 Food。node
客户端调用：编程

public class APP {
    public static void main(String[] args) {
        // 先选择一个具体的工厂
        FoodFactory factory = new ChineseFoodFactory();
        // 由第一步的工厂产生具体的对象，不一样的工厂造出不同的对象
        Food food = factory.makeFood("A");
    }
}

复制代码

虽然都是调用 makeFood("A") 制做 A 类食物，可是，不一样的工厂生产出来的彻底不同。设计模式
第一步，咱们须要选取合适的工厂，而后第二步基本上和简单工厂同样。数组
**核心在于，咱们须要在第一步选好咱们须要的工厂。**好比，咱们有 LogFactory 接口，实现类有 FileLogFactory 和 KafkaLogFactory，分别对应将日志写入文件和写入 Kafka 中，显然，咱们客户端第一步就须要决定到底要实例化 FileLogFactory 仍是 KafkaLogFactory，这将决定以后的全部的操做。缓存
虽然简单，不过我也把全部的构件都画到一张图上，这样看着比较清晰：安全

抽象工厂模式

当涉及到产品族的时候，就须要引入抽象工厂模式了。
一个经典的例子是造一台电脑。咱们先不引入抽象工厂模式，看看怎么实现。
由于电脑是由许多的构件组成的，咱们将 CPU 和主板进行抽象，而后 CPU 由 CPUFactory 生产，主板由 MainBoardFactory 生产，而后，咱们再将 CPU 和主板搭配起来组合在一块儿，以下图：

这个时候的客户端调用是这样的：

// 获得 Intel 的 CPU
CPUFactory cpuFactory = new IntelCPUFactory();
CPU cpu = intelCPUFactory.makeCPU();

// 获得 AMD 的主板
MainBoardFactory mainBoardFactory = new AmdMainBoardFactory();
MainBoard mainBoard = mainBoardFactory.make();

// 组装 CPU 和主板
Computer computer = new Computer(cpu, mainBoard);
复制代码

单独看 CPU 工厂和主板工厂，它们分别是前面咱们说的工厂模式。这种方式也容易扩展，由于要给电脑加硬盘的话，只须要加一个 HardDiskFactory 和相应的实现便可，不须要修改现有的工厂。bash
可是，这种方式有一个问题，那就是若是** Intel 家产的 CPU 和 AMD 产的主板不能兼容使用**，那么这代码就容易出错，由于客户端并不知道它们不兼容，也就会错误地出现随意组合。并发

-下面就是咱们要说的产品族的概念，它表明了组成某个产品的一系列附件的集合：app

当涉及到这种产品族的问题的时候，就须要抽象工厂模式来支持了。咱们再也不定义 CPU 工厂、主板工厂、硬盘工厂、显示屏工厂等等，咱们直接定义电脑工厂，每一个电脑工厂负责生产全部的设备，这样能保证确定不存在兼容问题。

这个时候，对于客户端来讲，再也不须要单独挑选 CPU厂商、主板厂商、硬盘厂商等，直接选择一家品牌工厂，品牌工厂会负责生产全部的东西，并且能保证确定是兼容可用的。

public static void main(String[] args) {
    // 第一步就要选定一个“大厂”
    ComputerFactory cf = new AmdFactory();
    // 从这个大厂造 CPU
    CPU cpu = cf.makeCPU();
    // 从这个大厂造主板
    MainBoard board = cf.makeMainBoard();
      // 从这个大厂造硬盘
      HardDisk hardDisk = cf.makeHardDisk();

    // 将同一个厂子出来的 CPU、主板、硬盘组装在一块儿
    Computer result = new Computer(cpu, board, hardDisk);
}
复制代码

固然，抽象工厂的问题也是显而易见的，好比咱们要加个显示器，就须要修改全部的工厂，给全部的工厂都加上制造显示器的方法。这有点违反了对修改关闭，对扩展开放这个设计原则。

单例模式

单例模式用得最多，错得最多。
饿汉模式最简单：

public class Singleton {
    // 首先，将 new Singleton() 堵死
    private Singleton() {};
    // 建立私有静态实例，意味着这个类第一次使用的时候就会进行建立
    private static Singleton instance = new Singleton();

    public static Singleton getInstance() {
        return instance;
    }
    // 瞎写一个静态方法。这里想说的是，若是咱们只是要调用 Singleton.getDate(...)，
    // 原本是不想要生成 Singleton 实例的，不过没办法，已经生成了
    public static Date getDate(String mode) {return new Date();}
}
复制代码

不少人都能说出饿汉模式的缺点，但是我以为生产过程当中，不多碰到这种状况：你定义了一个单例的类，不须要其实例，但是你却把一个或几个你会用到的静态方法塞到这个类中。

饱汉模式最容易出错：

public class Singleton {
    // 首先，也是先堵死 new Singleton() 这条路
    private Singleton() {}
    // 和饿汉模式相比，这边不须要先实例化出来，注意这里的 volatile，它是必须的
    private static volatile Singleton instance = null;

    public static Singleton getInstance() {
        if (instance == null) {
            // 加锁
            synchronized (Singleton.class) {
                // 这一次判断也是必须的，否则会有并发问题
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}
复制代码

双重检查，指的是两次检查 instance 是否为 null。 volatile 在这里是须要的，但愿能引发读者的关注。不少人不知道怎么写，直接就在 getInstance() 方法签名上加上 synchronized，这就很少说了，性能太差。

嵌套类最经典，之后你们就用它吧：

public class Singleton3 {

    private Singleton3() {}
    // 主要是使用了 嵌套类能够访问外部类的静态属性和静态方法 的特性
    private static class Holder {
        private static Singleton3 instance = new Singleton3();
    }
    public static Singleton3 getInstance() {
        return Holder.instance;
    }
}
复制代码

注意，不少人都会把这个嵌套类说成是静态内部类，严格地说，内部类和嵌套类是不同的，它们能访问的外部类权限也是不同的。

最后，必定有人跳出来讲用枚举实现单例，是的没错，枚举类很特殊，它在类加载的时候会初始化里面的全部的实例，并且 JVM 保证了它们不会再被实例化，因此它天生就是单例的。不说了，读者本身看着办吧，不建议使用。

建造者模式

常常遇见的 XxxBuilder 的类，一般都是建造者模式的产物。建造者模式其实有不少的变种，可是对于客户端来讲，咱们的使用一般都是一个模式的

Food food = new FoodBuilder().a().b().c().build();
Food food = Food.builder().a().b().c().build();
复制代码

套路就是先 new 一个 Builder，而后能够链式地调用一堆方法，最后再调用一次 build() 方法，咱们须要的对象就有了。
来一个中规中矩的建造者模式：

class User {
    // 下面是“一堆”的属性
    private String name;
    private String password;
    private String nickName;
    private int age;

    // 构造方法私有化，否则客户端就会直接调用构造方法了
    private User(String name, String password, String nickName, int age) {
        this.name = name;
        this.password = password;
        this.nickName = nickName;
        this.age = age;
    }
    // 静态方法，用于生成一个 Builder，这个不必定要有，不过写这个方法是一个很好的习惯，
    // 有些代码要求别人写 new User.UserBuilder().a()...build() 看上去就没那么好
    public static UserBuilder builder() {
        return new UserBuilder();
    }

    public static class UserBuilder {
        // 下面是和 User 如出一辙的一堆属性
        private String  name;
        private String password;
        private String nickName;
        private int age;

        private UserBuilder() {
        }

        // 链式调用设置各个属性值，返回 this，即 UserBuilder
        public UserBuilder name(String name) {
            this.name = name;
            return this;
        }

        public UserBuilder password(String password) {
            this.password = password;
            return this;
        }

        public UserBuilder nickName(String nickName) {
            this.nickName = nickName;
            return this;
        }

        public UserBuilder age(int age) {
            this.age = age;
            return this;
        }

        // build() 方法负责将 UserBuilder 中设置好的属性“复制”到 User 中。
        // 固然，能够在 “复制” 以前作点检验
        public User build() {
            if (name == null || password == null) {
                throw new RuntimeException("用户名和密码必填");
            }
            if (age <= 0 || age >= 150) {
                throw new RuntimeException("年龄不合法");
            }
            // 还能够作赋予”默认值“的功能
              if (nickName == null) {
                nickName = name;
            }
            return new User(name, password, nickName, age);
        }
    }
}

复制代码

核心是：先把全部的属性都设置给 Builder，而后 build() 方法的时候，将这些属性复制给实际产生的对象。
看看客户端的调用：

public class APP {
    public static void main(String[] args) {
        User d = User.builder()
                .name("foo")
                .password("pAss12345")
                .age(25)
                .build();
    }
}

复制代码

说实话，建造者模式的链式写法很吸引人，可是，多写了不少“无用”的 builder 的代码，感受这个模式没什么用。不过，当属性不少，并且有些必填，有些选填的时候，这个模式会使代码清晰不少。咱们能够在 Builder 的构造方法中强制让调用者提供必填字段，还有，在 build() 方法中校验各个参数比在 User 的构造方法中校验，代码要优雅一些。

题外话，强烈建议读者使用 lombok，用了 lombok 之后，上面的一大堆代码会变成以下这样:

@Builder
class User {
    private String  name;
    private String password;
    private String nickName;
    private int age;
}

复制代码

怎么样，省下来的时间是否是又能够干点别的了。

固然，若是你只是想要链式写法，不想要建造者模式，有个很简单的办法，User 的 getter 方法不变，全部的 setter 方法都让其 *return this 就能够了，而后就能够像下面这样调用：

User user = new User().setName("").setPassword("").setAge(20);

复制代码

原型模式

这是我要说的建立型模式的最后一个设计模式了。
原型模式很简单：有一个原型实例，基于这个原型实例产生新的实例，也就是“克隆”了。
Object 类中有一个 clone() 方法，它用于生成一个新的对象，固然，若是咱们要调用这个方法，java 要求咱们的类必须先实现 Cloneable 接口，此接口没有定义任何方法，可是不这么作的话，在 clone() 的时候，会抛出 CloneNotSupportedException 异常。

protected native Object clone() throws CloneNotSupportedException;

复制代码

java 的克隆是浅克隆，碰到对象引用的时候，克隆出来的对象和原对象中的引用将指向同一个对象。一般实现深克隆的方法是将对象进行序列化，而后再进行反序列化。

原型模式了解到这里我以为就够了，各类变着法子说这种代码或那种代码是原型模式，没什么意义。

建立型模式总结

建立型模式整体上比较简单，它们的做用就是为了产生实例对象，算是各类工做的第一步了，由于咱们写的是面向对象的代码，因此咱们第一步固然是须要建立一个对象了。
简单工厂模式最简单；工厂模式在简单工厂模式的基础上增长了选择工厂的维度，须要第一步选择合适的工厂；抽象工厂模式有产品族的概念，若是各个产品是存在兼容性问题的，就要用抽象工厂模式。单例模式就不说了，为了保证全局使用的是同一对象，一方面是安全性考虑，一方面是为了节省资源；建造者模式专门对付属性不少的那种类，为了让代码更优美；原型模式用得最少，了解和 Object 类中的 clone() 方法相关的知识便可。

结构型模式

前面建立型模式介绍了建立对象的一些设计模式，这节介绍的结构型模式旨在经过改变代码结构来达到解耦的目的，使得咱们的代码容易维护和扩展。

代理模式

第一个要介绍的代理模式是最常使用的模式之一了，用一个代理来隐藏具体实现类的实现细节，一般还用于在真实的实现的先后添加一部分逻辑。
既然说是代理，那就要对客户端隐藏真实实现，由代理来负责客户端的全部请求。固然，代理只是个代理，它不会完成实际的业务逻辑，而是一层皮而已，可是对于客户端来讲，它必须表现得就是客户端须要的真实实现。

理解代理这个词，这个模式其实就简单了。

public interface FoodService {
    Food makeChicken();
    Food makeNoodle();
}

public class FoodServiceImpl implements FoodService {
    public Food makeChicken() {
          Food f = new Chicken()
        f.setChicken("1kg");
          f.setSpicy("1g");
          f.setSalt("3g");
        return f;
    }
    public Food makeNoodle() {
        Food f = new Noodle();
        f.setNoodle("500g");
        f.setSalt("5g");
        return f;
    }
}

// 代理要表现得“就像是”真实实现类，因此须要实现 FoodService
public class FoodServiceProxy implements FoodService {

    // 内部必定要有一个真实的实现类，固然也能够经过构造方法注入
    private FoodService foodService = new FoodServiceImpl();

    public Food makeChicken() {
        System.out.println("咱们立刻要开始制做鸡肉了");

        // 若是咱们定义这句为核心代码的话，那么，核心代码是真实实现类作的，
        // 代理只是在核心代码先后作些“无足轻重”的事情
        Food food = foodService.makeChicken();

        System.out.println("鸡肉制做完成啦，加点胡椒粉"); // 加强
          food.addCondiment("pepper");

        return food;
    }
    public Food makeNoodle() {
        System.out.println("准备制做拉面~");
        Food food = foodService.makeNoodle();
        System.out.println("制做完成啦")
        return food;
    }
}

复制代码

客户端调用，注意，咱们要用代理来实例化接口：

// 这里用代理类来实例化
FoodService foodService = new FoodServiceProxy();
foodService.makeChicken();

复制代码

咱们发现没有，代理模式说白了就是作 “方法包装” 或作 “方法加强”。在面向切面编程中，算了仍是不要吹捧这个名词了，在 AOP 中，其实就是动态代理的过程。好比 Spring 中，咱们本身不定义代理类，可是 Spring 会帮咱们动态来定义代理，而后把咱们定义在 @Before、@After、@Around 中的代码逻辑动态添加到代理中。
说到动态代理，又能够展开说 …… Spring 中实现动态代理有两种，一种是若是咱们的类定义了接口，如 UserService 接口和 UserServiceImpl 实现，那么采用 JDK 的动态代理，感兴趣的读者能够去看看 java.lang.reflect.Proxy 类的源码；另外一种是咱们本身没有定义接口的，Spring 会采用 CGLIB 进行动态代理，它是一个 jar 包，性能还不错。

适配器模式

说完代理模式，说适配器模式，是由于它们很类似，这里能够作个比较。
适配器模式作的就是，有一个接口须要实现，可是咱们现成的对象都不知足，须要加一层适配器来进行适配
适配器模式整体来讲分三种：默认适配器模式、对象适配器模式、类适配器模式。先不急着分清楚这几个，先看看例子再说。

默认适配器模式

首先，咱们先看看最简单的适配器模式**默认适配器模式(Default Adapter)**是怎么样的。
咱们用 Appache commons-io 包中的 FileAlterationListener 作例子，此接口定义了不少的方法，用于对文件或文件夹进行监控，一旦发生了对应的操做，就会触发相应的方法。

public interface FileAlterationListener {
    void onStart(final FileAlterationObserver observer);
    void onDirectoryCreate(final File directory);
    void onDirectoryChange(final File directory);
    void onDirectoryDelete(final File directory);
    void onFileCreate(final File file);
    void onFileChange(final File file);
    void onFileDelete(final File file);
    void onStop(final FileAlterationObserver observer);
}

复制代码

此接口的一大问题是抽象方法太多了，若是咱们要用这个接口，意味着咱们要实现每个抽象方法，若是咱们只是想要监控文件夹中的文件建立和文件删除事件，但是咱们仍是不得不实现全部的方法，很明显，这不是咱们想要的。
因此，咱们须要下面的一个适配器，它用于实现上面的接口，可是全部的方法都是空方法，这样，咱们就能够转而定义本身的类来继承下面这个类便可。

public class FileAlterationListenerAdaptor implements FileAlterationListener {

    public void onStart(final FileAlterationObserver observer) {
    }

    public void onDirectoryCreate(final File directory) {
    }

    public void onDirectoryChange(final File directory) {
    }

    public void onDirectoryDelete(final File directory) {
    }

    public void onFileCreate(final File file) {
    }

    public void onFileChange(final File file) {
    }

    public void onFileDelete(final File file) {
    }

    public void onStop(final FileAlterationObserver observer) {
    }
}

复制代码

好比咱们能够定义如下类，咱们仅仅须要实现咱们想实现的方法就能够了：

public class FileMonitor extends FileAlterationListenerAdaptor {
    public void onFileCreate(final File file) {
        // 文件建立
        doSomething();
    }

    public void onFileDelete(final File file) {
        // 文件删除
        doSomething();
    }
}
复制代码

固然，上面说的只是适配器模式的其中一种，也是最简单的一种，无需多言。下面，再介绍“正统的”适配器模式。

对象适配器模式

来看一个《Head First 设计模式》中的一个例子，我稍微修改了一下，看看怎么将鸡适配成鸭，这样鸡也能当鸭来用。由于，如今鸭这个接口，咱们没有合适的实现类能够用，因此须要适配器。

public interface Duck {
    public void quack(); // 鸭的呱呱叫
      public void fly(); // 飞
}

public interface Cock {
    public void gobble(); // 鸡的咕咕叫
      public void fly(); // 飞
}

public class WildCock implements Cock {
    public void gobble() {
        System.out.println("咕咕叫");
    }
      public void fly() {
        System.out.println("鸡也会飞哦");
    }
}

复制代码

鸭接口有 fly() 和 quare() 两个方法，鸡 Cock 若是要冒充鸭，fly() 方法是现成的，可是鸡不会鸭的呱呱叫，没有 quack() 方法。这个时候就须要适配了：

// 毫无疑问，首先，这个适配器确定须要 implements Duck，这样才能当作鸭来用
public class CockAdapter implements Duck {

    Cock cock;
    // 构造方法中须要一个鸡的实例，此类就是将这只鸡适配成鸭来用
      public CockAdapter(Cock cock) {
        this.cock = cock;
    }

    // 实现鸭的呱呱叫方法
      @Override
      public void quack() {
        // 内部实际上是一只鸡的咕咕叫
        cock.gobble();
    }

      @Override
      public void fly() {
        cock.fly();
    }
}

复制代码

客户端调用很简单了：

public static void main(String[] args) {
    // 有一只野鸡
      Cock wildCock = new WildCock();
      // 成功将野鸡适配成鸭
      Duck duck = new CockAdapter(wildCock);
      ...
}

复制代码

到这里，你们也就知道了适配器模式是怎么回事了。无非是咱们须要一只鸭，可是咱们只有一只鸡，这个时候就须要定义一个适配器，由这个适配器来充当鸭，可是适配器里面的方法仍是由鸡来实现的。
咱们用一个图来简单说明下：

上图应该仍是很容易理解的，我就不作更多的解释了。下面，咱们看看类适配模式怎么样的。

类适配器模式

废话少说，直接上图：

看到这个图，你们应该很容易理解的吧，经过继承的方法，适配器自动得到了所须要的大部分方法。这个时候，客户端使用更加简单，直接 Target t = new SomeAdapter(); 就能够了。

适配器模式总结

类适配和对象适配的异同
- 一个采用继承，一个采用组合；
- 类适配属于静态实现，对象适配属于组合的动态实现，对象适配须要多实例化一个对象。
- 整体来讲，对象适配用得比较多。
适配器模式和代理模式的异同
- 比较这两种模式，实际上是比较对象适配器模式和代理模式，在代码结构上，它们很类似，都须要一个具体的实现类的实例。可是它们的目的不同，代理模式作的是加强原方法的活；适配器作的是适配的活，为的是提供“把鸡包装成鸭，而后当作鸭来使用”，而鸡和鸭它们之间本来没有继承关系。

桥梁模式

理解桥梁模式，其实就是理解代码抽象和解耦。
咱们首先须要一个桥梁，它是一个接口，定义提供的接口方法。

public interface DrawAPI {
   public void draw(int radius, int x, int y);
}
复制代码

而后是一系列实现类：

public class RedPen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用红色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class GreenPen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用绿色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class BluePen implements DrawAPI {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用蓝色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
复制代码

定义一个抽象类，此类的实现类都须要使用 DrawAPI：

public abstract class Shape {
   protected DrawAPI drawAPI;

   protected Shape(DrawAPI drawAPI){
      this.drawAPI = drawAPI;
   }
   public abstract void draw();    
}
复制代码

定义抽象类的子类：

// 圆形
public class Circle extends Shape {
   private int radius;

   public Circle(int radius, DrawAPI drawAPI) {
      super(drawAPI);
      this.radius = radius;
   }

   public void draw() {
      drawAPI.draw(radius, 0, 0);
   }
}
// 长方形
public class Rectangle extends Shape {
    private int x;
      private int y;

      public Rectangle(int x, int y, DrawAPI drawAPI) {
        super(drawAPI);
          this.x = x;
          this.y = y;
    }
      public void draw() {
      drawAPI.draw(0, x, y);
   }
}

复制代码

最后，咱们来看客户端演示：

public static void main(String[] args) {
    Shape greenCircle = new Circle(10, new GreenPen());
      Shape redRectangle = new Rectangle(4, 8, new RedPen());

      greenCircle.draw();
      redRectangle.draw();
}

复制代码

可能你们看上面一步步还不是特别清晰，我把全部的东西整合到一张图上：

这回你们应该就知道抽象在哪里，怎么解耦了吧。桥梁模式的优势也是显而易见的，就是很是容易进行扩展。

装饰模式

要把装饰模式说清楚明白，不是件容易的事情。也许读者知道 Java IO 中的几个类是典型的装饰模式的应用，可是读者不必定清楚其中的关系，也许看完就忘了，但愿看完这节后，读者能够对其有更深的感悟。
首先，咱们先看一个简单的图，看这个图的时候，了解下层次结构就能够了：

咱们来讲说装饰模式的出发点，从图中能够看到，接口 Component其实已经有了 ConcreteComponentA 和 ConcreteComponentB 两个实现类了，可是，若是咱们要加强这两个实现类的话，咱们就能够采用装饰模式，用具体的装饰器来装饰实现类，以达到加强的目的。

从名字来简单解释下装饰器。既然说是装饰，那么每每就是添加小功能这种，并且，咱们要知足能够添加多个小功能。最简单的，代理模式就能够实现功能的加强，可是代理不容易实现多个功能的加强，固然你能够说用代理包装代理的方式，可是那样的话代码就复杂了。

首先明白一些简单的概念，从图中咱们看到，全部的具体装饰者们 ConcreteDecorator
均可以做为 Component 来使用，由于它们都实现了 Component 中的全部接口。它们和 Component 实现类 ConcreteComponent 的区别是，它们只是装饰者，起装饰做用，也就是即便它们看上去牛逼轰轰，可是它们都只是在具体的实现中加了层皮来装饰而已。

注意这段话中混杂在各个名词中的 Component 和 Decorator，别搞混了。

下面来看看一个例子，先把装饰模式弄清楚，而后再介绍下 java io 中的装饰模式的应用。
最近大街上流行起来了“快乐柠檬”，咱们把快乐柠檬的饮料分为三类：红茶、绿茶、咖啡，在这三大类的基础上，又增长了许多的口味，什么金桔柠檬红茶、金桔柠檬珍珠绿茶、芒果红茶、芒果绿茶、芒果珍珠红茶、烤珍珠红茶、烤珍珠芒果绿茶、椰香胚芽咖啡、焦糖可可咖啡等等，每家店都有很长的菜单，可是仔细看下，其实原料也没几样，可是能够搭配出不少组合，若是顾客须要，不少没出如今菜单中的饮料他们也是能够作的。
在这个例子中，红茶、绿茶、咖啡是最基础的饮料，其余的像金桔柠檬、芒果、珍珠、椰果、焦糖等都属于装饰用的。固然，在开发中，咱们确实能够像门店同样，开发这些类：LemonBlackTea、LemonGreenTea、MangoBlackTea、MangoLemonGreenTea......可是，很快咱们就发现，这样子干确定是不行的，这会致使咱们须要组合出全部的可能，并且若是客人须要在红茶中加双份柠檬怎么办？三份柠檬怎么办？万一有个变态要四份柠檬，因此这种作法是给本身找加班的。
不说废话了，上代码。
首先，定义饮料抽象基类：

public abstract class Beverage {
      // 返回描述
      public abstract String getDescription();
      // 返回价格
      public abstract double cost();
}
复制代码

而后是三个基础饮料实现类，红茶、绿茶和咖啡：

public class BlackTea extends Beverage {
      public String getDescription() {
        return "红茶";
    }
      public double cost() {
        return 10;
    }
}
public class GreenTea extends Beverage {
    public String getDescription() {
        return "绿茶";
    }
      public double cost() {
        return 11;
    }
}
...// 咖啡省略
复制代码

定义调料，也就是装饰者的基类，此类必须继承自 Beverage：

// 调料
public abstract class Condiment extends Beverage {

}

复制代码

而后咱们来定义柠檬、芒果等具体的调料，它们属于装饰者，毫无疑问，这些调料确定都须要继承 Condiment 类：

public class Lemon extends Condiment {
    private Beverage bevarage;
      // 这里很关键，须要传入具体的饮料，如须要传入没有被装饰的红茶或绿茶，
      // 固然也能够传入已经装饰好的芒果绿茶，这样能够作芒果柠檬绿茶
      public Lemon(Beverage bevarage) {
        this.bevarage = bevarage;
    }
      public String getDescription() {
        // 装饰
        return bevarage.getDescription() + ", 加柠檬";
    }
      public double cost() {
          // 装饰
        return beverage.cost() + 2; // 加柠檬须要 2 元
    }
}
public class Mango extends Condiment {
    private Beverage bevarage;
      public Mango(Beverage bevarage) {
        this.bevarage = bevarage;
    }
      public String getDescription() {
        return bevarage.getDescription() + ", 加芒果";
    }
      public double cost() {
        return beverage.cost() + 3; // 加芒果须要 3 元
    }
}
...// 给每一种调料都加一个类
复制代码

看客户端调用

public static void main(String[] args) {
      // 首先，咱们须要一个基础饮料，红茶、绿茶或咖啡
    Beverage beverage = new GreenTea();
      // 开始装饰
      beverage = new Lemon(beverage); // 先加一份柠檬
      beverage = new Mongo(beverage); // 再加一份芒果

      System.out.println(beverage.getDescription() + " 价格：￥" + beverage.cost());
      //"绿茶, 加柠檬, 加芒果 价格：￥16"
}
复制代码

若是咱们须要芒果珍珠双份柠檬红茶：

Beverage beverage = new Mongo(new Pearl(new Lemon(new Lemon(new BlackTea()))));
复制代码

是否是很变态？
看看下图可能会清晰一些：

到这里，你们应该已经清楚装饰模式了吧。
下面，咱们再来讲说 java IO 中的装饰模式。看下图 InputStream 派生出来的部分类

咱们知道 InputStream 表明了输入流，具体的输入来源能够是文件（FileInputStream）、管道（PipedInputStream）、数组（ByteArrayInputStream）等，这些就像前面奶茶的例子中的红茶、绿茶，属于基础输入流。
FilterInputStream 承接了装饰模式的关键节点，其实现类是一系列装饰器，好比 BufferedInputStream 表明用缓冲来装饰，也就使得输入流具备了缓冲的功能，LineNumberInputStream 表明用行号来装饰，在操做的时候就能够取得行号了，DataInputStream 的装饰，使得咱们能够从输入流转换为 java 中的基本类型值。
固然，在 java IO 中，若是咱们使用装饰器的话，就不太适合面向接口编程了，如：

InputStream inputStream = new LineNumberInputStream(new BufferedInputStream(new FileInputStream("")));
复制代码

这样的结果是，InputStream 仍是不具备读取行号的功能，由于读取行号的方法定义在 LineNumberInputStream 类中。
咱们应该像下面这样使用：

DataInputStream is = new DataInputStream(
                              new BufferedInputStream(
                                  new FileInputStream("")));

复制代码

因此说嘛，要找到纯的严格符合设计模式的代码仍是比较难的

门面模式

门面模式（也叫外观模式，Facade Pattern）在许多源码中有使用，好比 slf4j 就能够理解为是门面模式的应用。这是一个简单的设计模式，咱们直接上代码再说吧。
首先，咱们定义一个接口：

public interface Shape {
   void draw();
}

复制代码

定义几个实现类：

public class Circle implements Shape {

   @Override
   public void draw() {
      System.out.println("Circle::draw()");
   }
}

public class Rectangle implements Shape {

   @Override
   public void draw() {
      System.out.println("Rectangle::draw()");
   }
}

复制代码

客户端调用：

public static void main(String[] args) {
    // 画一个圆形
      Shape circle = new Circle();
      circle.draw();

      // 画一个长方形
      Shape rectangle = new Rectangle();
      rectangle.draw();
}

复制代码

以上是咱们常写的代码，咱们须要画圆就要先实例化圆，画长方形就须要先实例化一个长方形，而后再调用相应的 draw() 方法。
下面，咱们看看怎么用门面模式来让客户端调用更加友好一些。
咱们先定义一个门面：

public class ShapeMaker {
   private Shape circle;
   private Shape rectangle;
   private Shape square;

   public ShapeMaker() {
      circle = new Circle();
      rectangle = new Rectangle();
      square = new Square();
   }

  /**
   * 下面定义一堆方法，具体应该调用什么方法，由这个门面来决定
   */

   public void drawCircle(){
      circle.draw();
   }
   public void drawRectangle(){
      rectangle.draw();
   }
   public void drawSquare(){
      square.draw();
   }
}

复制代码

看看如今客户端怎么调用：

public static void main(String[] args) {
  ShapeMaker shapeMaker = new ShapeMaker();

  // 客户端调用如今更加清晰了
  shapeMaker.drawCircle();
  shapeMaker.drawRectangle();
  shapeMaker.drawSquare();        
}

复制代码

门面模式的优势显而易见，客户端再也不须要关注实例化时应该使用哪一个实现类，直接调用门面提供的方法就能够了，由于门面类提供的方法的方法名对于客户端来讲已经很友好了。

组合模式

组合模式用于表示具备层次结构的数据，使得咱们对单个对象和组合对象的访问具备一致性。
直接看一个例子吧，每一个员工都有姓名、部门、薪水这些属性，同时还有下属员工集合（虽然可能集合为空），而下属员工和本身的结构是同样的，也有姓名、部门这些属性，同时也有他们的下属员工集合。

public class Employee {
   private String name;
   private String dept;
   private int salary;
   private List<Employee> subordinates; // 下属

   public Employee(String name,String dept, int sal) {
      this.name = name;
      this.dept = dept;
      this.salary = sal;
      subordinates = new ArrayList<Employee>();
   }

   public void add(Employee e) {
      subordinates.add(e);
   }

   public void remove(Employee e) {
      subordinates.remove(e);
   }

   public List<Employee> getSubordinates(){
     return subordinates;
   }

   public String toString(){
      return ("Employee :[ Name : " + name + ", dept : " + dept + ", salary :" + salary+" ]");
   }   
}
复制代码

一般，这种类须要定义 add(node)、remove(node)、getChildren() 这些方法。
这说的其实就是组合模式，这种简单的模式我就不作过多介绍了，相信各位读者也不喜欢看我写废话。

享元模式

英文是 Flyweight Pattern，不知道是谁最早翻译的这个词，感受这翻译真的很差理解，咱们试着强行关联起来吧。Flyweight 是轻量级的意思，享元分开来讲就是共享元器件，也就是复用已经生成的对象，这种作法固然也就是轻量级的了。
复用对象最简单的方式是，用一个 HashMap 来存放每次新生成的对象。每次须要一个对象的时候，先到 HashMap 中看看有没有，若是没有，再生成新的对象，而后将这个对象放入 HashMap 中。
这种简单的代码我就不演示了。

结构型模式总结

前面，咱们说了代理模式、适配器模式、桥梁模式、装饰模式、门面模式、组合模式和享元模式。读者是否能够分别把这几个模式说清楚了呢？在说到这些模式的时候，心中是否有一个清晰的图或处理流程在脑海里呢？
代理模式是作方法加强的，适配器模式是把鸡包装成鸭这种用来适配接口的，桥梁模式作到了很好的解耦，装饰模式从名字上就看得出来，适合于装饰类或者说是加强类的场景，门面模式的优势是客户端不须要关心实例化过程，只要调用须要的方法便可，组合模式用于描述具备层次结构的数据，享元模式是为了在特定的场景中缓存已经建立的对象，用于提升性能。

行为型模式

行为型模式关注的是各个类之间的相互做用，将职责划分清楚，使得咱们的代码更加地清晰。

策略模式

策略模式太经常使用了，因此把它放到最前面进行介绍。它比较简单，我就不废话，直接用代码说事吧。
下面设计的场景是，咱们须要画一个图形，可选的策略就是用红色笔来画，仍是绿色笔来画，或者蓝色笔来画。
首先，先定义一个策略接口：

public interface Strategy {
   public void draw(int radius, int x, int y);
}
复制代码

而后咱们定义具体的几个策略：

public class RedPen implements Strategy {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用红色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class GreenPen implements Strategy {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用绿色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}
public class BluePen implements Strategy {
   @Override
   public void draw(int radius, int x, int y) {
      System.out.println("用蓝色笔画图，radius:" + radius + ", x:" + x + ", y:" + y);
   }
}

复制代码

使用策略的类：

public class Context {
   private Strategy strategy;

   public Context(Strategy strategy){
      this.strategy = strategy;
   }

   public int executeDraw(int radius, int x, int y){
      return strategy.draw(radius, x, y);
   }
}
复制代码

客户端演示：

public static void main(String[] args) {
    Context context = new Context(new BluePen()); // 使用绿色笔来画
      context.executeDraw(10, 0, 0);
}

复制代码

放到一张图上，让你们看得清晰些：

这个时候，你们有没有联想到结构型模式中的桥梁模式，它们其实很是类似，我把桥梁模式的图拿过来你们对比下：

要我说的话，它们很是类似，桥梁模式在左侧加了一层抽象而已。桥梁模式的耦合更低，结构更复杂一些。

观察者模式

观察者模式对于咱们来讲，真是再简单不过了。无外乎两个操做，观察者订阅本身关心的主题和主题有数据变化后通知观察者们。
首先，须要定义主题，每一个主题须要持有观察者列表的引用，用于在数据变动的时候通知各个观察者：

public class Subject {

   private List<Observer> observers = new ArrayList<Observer>();
   private int state;

   public int getState() {
      return state;
   }

   public void setState(int state) {
      this.state = state;
      // 数据已变动，通知观察者们
      notifyAllObservers();
   }

   public void attach(Observer observer){
      observers.add(observer);        
   }

   // 通知观察者们
   public void notifyAllObservers(){
      for (Observer observer : observers) {
         observer.update();
      }
   }     
}

复制代码

定义观察者接口：

public abstract class Observer {
   protected Subject subject;
   public abstract void update();
}

复制代码

其实若是只有一个观察者类的话，接口都不用定义了，不过，一般场景下，既然用到了观察者模式，咱们就是但愿一个事件出来了，会有多个不一样的类须要处理相应的信息。好比，订单修改为功事件，咱们但愿发短信的类获得通知、发邮件的类获得通知、处理物流信息的类获得通知等。
咱们来定义具体的几个观察者类：

public class BinaryObserver extends Observer {

      // 在构造方法中进行订阅主题
    public BinaryObserver(Subject subject) {
        this.subject = subject;
        // 一般在构造方法中将 this 发布出去的操做必定要当心
        this.subject.attach(this);
    }

      // 该方法由主题类在数据变动的时候进行调用
    @Override
    public void update() {
        String result = Integer.toBinaryString(subject.getState());
        System.out.println("订阅的数据发生变化，新的数据处理为二进制值为：" + result);
    }
}

public class HexaObserver extends Observer {

    public HexaObserver(Subject subject) {
        this.subject = subject;
        this.subject.attach(this);
    }

    @Override
    public void update() {
          String result = Integer.toHexString(subject.getState()).toUpperCase();
        System.out.println("订阅的数据发生变化，新的数据处理为十六进制值为：" + result);
    }
}

复制代码

客户端使用也很是简单：

public static void main(String[] args) {
    // 先定义一个主题
      Subject subject1 = new Subject();
      // 定义观察者
      new BinaryObserver(subject1);
      new HexaObserver(subject1);

      // 模拟数据变动，这个时候，观察者们的 update 方法将会被调用
      subject.setState(11);
}

复制代码

output:

订阅的数据发生变化，新的数据处理为二进制值为：1011
订阅的数据发生变化，新的数据处理为十六进制值为：B

复制代码

固然，jdk 也提供了类似的支持，具体的你们能够参考 java.util.Observable 和 java.util.Observer 这两个类。
实际生产过程当中，观察者模式每每用消息中间件来实现，若是要实现单机观察者模式，笔者建议读者使用 Guava 中的 EventBus，它有同步实现也有异步实现，本文主要介绍设计模式，就不展开说了。

责任链模式

责任链一般须要先创建一个单向链表，而后调用方只须要调用头部节点就能够了，后面会自动流转下去。好比流程审批就是一个很好的例子，只要终端用户提交申请，根据申请的内容信息，自动创建一条责任链，而后就能够开始流转了
有这么一个场景，用户参加一个活动能够领取奖品，可是活动须要进行不少的规则校验而后才能放行，好比首先须要校验用户是不是新用户、今日参与人数是否有限额、全场参与人数是否有限额等等。设定的规则都经过后，才能让用户领走奖品。

若是产品给你这个需求的话，我想大部分人一开始确定想的就是，用一个 List 来存放全部的规则，而后 foreach 执行一下每一个规则就行了。不过，读者也先别急，看看责任链模式和咱们说的这个有什么不同？

首先，咱们要定义流程上节点的基类：

public abstract class RuleHandler {

      // 后继节点
    protected RuleHandler successor;

    public abstract void apply(Context context);

    public void setSuccessor(RuleHandler successor) {
        this.successor = successor;
    }
    public RuleHandler getSuccessor() {
        return successor;
    }
}

复制代码

接下来，咱们须要定义具体的每一个节点了。
校验用户是不是新用户：

public class NewUserRuleHandler extends RuleHandler {

    public void apply(Context context) {
        if (context.isNewUser()) {
              // 若是有后继节点的话，传递下去
            if (this.getSuccessor() != null) {
                this.getSuccessor().apply(context);
            }
        } else {
            throw new RuntimeException("该活动仅限新用户参与");
        }
    }

}

复制代码

校验用户所在地区是否能够参与：

public class LocationRuleHandler extends RuleHandler {
    public void apply(Context context) {
        boolean allowed = activityService.isSupportedLocation(context.getLocation);
          if (allowed) {
            if (this.getSuccessor() != null) {
                this.getSuccessor().apply(context);
            }
        } else  {
            throw new RuntimeException("很是抱歉，您所在的地区没法参与本次活动");
        }
    }
}

复制代码

校验奖品是否已领完：

public class LimitRuleHandler extends RuleHandler {
    public void apply(Context context) {
          int remainedTimes = activityService.queryRemainedTimes(context); // 查询剩余奖品
        if (remainedTimes > 0) {
            if (this.getSuccessor() != null) {
                this.getSuccessor().apply(userInfo);
            }
        } else {
            throw new RuntimeException("您来得太晚了，奖品被领完了");
        }
    }
}

复制代码

客户端：

public static void main(String[] args) {
    RuleHandler newUserHandler = new NewUserRuleHandler();
      RuleHandler locationHandler = new LocationRuleHandler();
      RuleHandler limitHandler = new LimitRuleHandler();

      // 假设本次活动仅校验地区和奖品数量，不校验新老用户
      locationHandler.setSuccessor(limitHandler);
      locationHandler.apply(context);
}

复制代码

代码其实很简单，就是先定义好一个链表，而后在经过任意一节点后，若是此节点有后继节点，那么传递下去。
至于它和咱们前面说的用一个 List 存放须要执行的规则的作法有什么异同，留给读者本身琢磨吧。

模板方法模式

在含有继承结构的代码中，模板方法模式是很是经常使用的，这也是在开源代码中大量被使用的。
一般会有一个抽象类：

public abstract class AbstractTemplate {
    // 这就是模板方法
      public void templateMethod(){
        init();
        apply(); // 这个是重点
        end(); // 能够做为钩子方法
    }
    protected void init() {
        System.out.println("init 抽象层已经实现，子类也能够选择覆写");
    }
      // 留给子类实现
    protected abstract void apply();
    protected void end() {
    }
}

复制代码

模板方法中调用了 3 个方法，其中 apply() 是抽象方法，子类必须实现它，其实模板方法中有几个抽象方法彻底是自由的，咱们也能够将三个方法都设置为抽象方法，让子类来实现。也就是说，模板方法只负责定义第一步应该要作什么，第二步应该作什么，第三步应该作什么，至于怎么作，由子类来实现。
咱们写一个实现类：

public class ConcreteTemplate extends AbstractTemplate {
    public void apply() {
        System.out.println("子类实现抽象方法 apply");
    }
      public void end() {
        System.out.println("咱们能够把 method3 当作钩子方法来使用，须要的时候覆写就能够了");
    }
}

复制代码

客户端调用演示：

public static void main(String[] args) {
    AbstractTemplate t = new ConcreteTemplate();
      // 调用模板方法
      t.templateMethod();
}

复制代码

代码其实很简单，基本上看到就懂了，关键是要学会用到本身的代码中。

状态模式

废话我就不说了，咱们说一个简单的例子。商品库存中心有个最基本的需求是减库存和补库存，咱们看看怎么用状态模式来写。
核心在于，咱们的关注点再也不是 Context 是该进行哪一种操做，而是关注在这个 Context 会有哪些操做。
定义状态接口：

public interface State {
   public void doAction(Context context);
}

复制代码

定义减库存的状态：

public class DeductState implements State {

   public void doAction(Context context) {
      System.out.println("商品卖出，准备减库存");
      context.setState(this);

      //... 执行减库存的具体操做
   }

   public String toString(){
      return "Deduct State";
   }
}

复制代码

定义补库存状态：

public class RevertState implements State {
    public void doAction(Context context) {
        System.out.println("给此商品补库存");
          context.setState(this);

          //... 执行加库存的具体操做
    }
      public String toString() {
        return "Revert State";
    }
}

复制代码

前面用到了 context.setState(this)，咱们来看看怎么定义 Context 类：

public class Context {
    private State state;
      private String name;
      public Context(String name) {
        this.name = name;
    }

      public void setState(State state) {
        this.state = state;
    }
      public void getState() {
        return this.state;
    }
}

复制代码

咱们来看下客户端调用，你们就一清二楚了：

public static void main(String[] args) {
    // 咱们须要操做的是 iPhone X
    Context context = new Context("iPhone X");

    // 看看怎么进行补库存操做
      State revertState = new RevertState();
      revertState.doAction(context);

    // 一样的，减库存操做也很是简单
      State deductState = new DeductState();
      deductState.doAction(context);

      // 若是须要咱们能够获取当前的状态
    // context.getState().toString();
}

复制代码

读者可能会发现，在上面这个例子中，若是咱们不关心当前 context 处于什么状态，那么 Context 就能够不用维护 state 属性了，那样代码会简单不少。
不过，商品库存这个例子毕竟只是个例，咱们还有不少实例是须要知道当前 context 处于什么状态的。

行为型模式总结

行为型模式部分介绍了策略模式、观察者模式、责任链模式、模板方法模式和状态模式，其实，经典的行为型模式还包括备忘录模式、命令模式等，可是它们的使用场景比较有限，并且本文篇幅也挺大了，我就不进行介绍了。

总结

学习设计模式的目的是为了让咱们的代码更加的优雅、易维护、易扩展。此次整理这篇文章，让我从新审视了一下各个设计模式，对我本身而言收获仍是挺大的。我想，文章的最大收益者通常都是做者本人，为了写一篇文章，须要巩固本身的知识，须要寻找各类资料，并且，本身写过的才最容易记住，也算是我给读者的建议吧。