【◉设计模式】设计模式

设计模式的六大原则

开闭原则：对扩展开放，对修改关闭，多使用抽象类和接口。
里氏替换原则：基类可以被子类替换，使用抽象类继承，不使用具体类继承。
依赖倒转原则：要依赖于抽象，不要依赖于具体，针对接口编程，不针对实现编程。
接口隔离原则：使用多个隔离的接口，比使用单个接口好，建立最小的接口。
迪米特法则：一个软件实体应当尽可能少地与其他实体发生相互作用，通过中间类建立联系。
合成复用原则：尽量使用合成/聚合，而不是使用继承。

单例模式

单例模式（Singleton），目的是为了保证在一个进程中，某个类有且仅有一个实例。

由于这个类只有一个实例，所以不能让调用方使用new Xxx()来创建实例。所以，单例的构造方法必须是private，这样就防止了调用方自己创建实例。

单例模式的实现需要三个必要的条件：

单例类的构造函数必须是私有的，这样才能将类的创建权控制在类的内部，从而使得类的外部不能创建类的实例。
单例类通过一个私有的静态变量来存储其唯一实例。
单例类通过提供一个公开的静态方法，使得外部使用者可以访问类的唯一实例。

另外，实现单例类时，还需要考虑三个问题：

创建单例对象时，是否线程安全。
单例对象的创建，是否延时加载。
获取单例对象时，是否需要加锁。

饿汉模式

JVM在类的初始化阶段，会执行类的静态方法。在执行类的初始化期间，JVM会去获取Class对象的锁。这个锁可以同步多个线程对同一个类的初始化。

饿汉模式只在类加载的时候创建一次实例，没有多线程同步的问题。单例没有用到也会被创建，内存就被浪费了。

public class Singleton {  
    private static Singleton instance = new Singleton();  
    private Singleton() {}  
    public static Singleton newInstance() {
        return instance;  
    }  
}

饿汉式单例的优点：

单例对象的创建是线程安全的；
获取单例对象时不需要加锁。

饿汉式单例的缺点：

单例对象的创建，不是延时加载。

懒汉式

与饿汉式思想不同，懒汉式支持延时加载，将对象的创建延迟到了获取对象的时候。不过为了线程安全，在获取对象的操作需要加锁，这就导致了低性能。

public class Singleton { 
    private static final Singleton instance;

    private Singleton () {}

    public static synchronized Singleton getInstance() {    
        if (instance == null) {      
            instance = new Singleton();    
        }    

        return instance;  
    }
}

上述代码加的锁只有在第一次创建对象时有用，而之后每次获取对象，其实是不需要加锁的（双重检查锁定优化了这个问题）。

懒汉式单例优点：

对象的创建是线程安全的。
支持延时加载。

懒汉式单例缺点：

获取对象的操作被加上了锁，影响了并发性能。

双重检查锁定

双重检查锁定将懒汉式中的 synchronized 方法改成了 synchronized 代码块。如下：

public class Singleton {  
    private static volatile Singleton instance = null;  //volatile
    private Singleton(){}  
    public static Singleton getInstance() {  
        if (instance == null) {  
            synchronized (Singleton.class) {  
                if (instance == null) {
                    instance = new Singleton();  
                }  
            }  
        }  
        return instance;  
    }  
}

双重校验锁先判断 instance 是否已经被实例化，如果没有被实例化，那么才对实例化语句进行加锁。

instance使用static修饰的原因：getInstance为静态方法，因为静态方法的内部不能直接使用非静态变量，只有静态成员才能在没有创建对象时进行初始化，所以返回的这个实例必须是静态的。

为什么两次判断instance == null

new Singleton()会执行三个动作：分配内存空间、初始化对象和对象引用指向内存地址。

memory = allocate();　　// 1：分配对象的内存空间
ctorInstance(memory);　 // 2：初始化对象
instance = memory;　　  // 3：设置instance指向刚分配的内存地址

由于指令重排优化的存在，导致初始化对象和将对象引用指向内存地址的顺序是不确定的。在某个线程创建单例对象时，会为该对象分配了内存空间并将对象的字段设置为默认值。此时就可以将分配的内存地址赋值给instance字段了，然而该对象可能还没有初始化。若紧接着另外一个线程来调用getInstance，取到的是未初始化的对象，程序就会出错。volatile 可以禁止指令重排序，保证了先初始化对象再赋值给instance变量。

双重检查锁定单例优点：

对象的创建是线程安全的。
支持延时加载。
获取对象时不需要加锁。

静态内部类

它与饿汉模式一样，也是利用了类初始化机制，因此不存在多线程并发的问题。不一样的是，它是在内部类里面去创建对象实例。这样的话，只要应用中不使用内部类，JVM就不会去加载这个单例类，也就不会创建单例对象，从而实现懒汉式的延迟加载。也就是说这种方式可以同时保证延迟加载和线程安全。

基于类初始化的方案的实现代码更简洁。

public class Instance {
    private static class InstanceHolder {
        public static Instance instance = new Instance();
    }
    private Instance() {}
    public static Instance getInstance() {
        return InstanceHolder.instance ;　　// 这里将导致InstanceHolder类被初始化
    }
}

如上述代码，InstanceHolder 是一个静态内部类，当外部类 Instance 被加载的时候，并不会创建 InstanceHolder 实例对象。

只有当调用 getInstance() 方法时，InstanceHolder 才会被加载，这个时候才会创建 Instance。Instance 的唯一性、创建过程的线程安全性，都由 JVM 来保证。

静态内部类单例优点：

对象的创建是线程安全的。
支持延时加载。
获取对象时不需要加锁。

枚举

用枚举来实现单例，是最简单的方式。这种实现方式通过Java 枚举类型本身的特性，保证了实例创建的线程安全性和实例的唯一性。

public enum Singleton {
    INSTANCE; // 该对象全局唯一
}

工厂模式

工厂模式是用来封装对象的创建。工厂模式有三种，它们分别是简单工厂模式，工厂方法模式以及抽象工厂模式，通常我们所说的工厂模式指的是工厂方法模式。

简单工厂模式

定义一个工厂类，根据传入的参数不同返回不同的实例，被创建的实例具有共同的父类或接口。

由于只有一个工厂类，所以工厂类中创建的对象不能太多，否则工厂类的业务逻辑就太复杂了，其次由于工厂类封装了对象的创建过程，所以客户端不关心对象的创建。

适用场景：

需要创建的对象较少。
客户端不关心对象的创建过程。

我们创建一个可以绘制不同形状的绘图工具，可以绘制圆形，正方形，三角形，每个图形都会有一个draw()方法用于绘图。

public interface Shape {
    void draw();
}

编写具体的图形，每种图形都实现Shape接口。

public class CircleShape implements Shape {

    public CircleShape() {
        System.out.println(  "CircleShape: created");
    }

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

}

public class RectShape implements Shape {
    public RectShape() {
        System.out.println(  "RectShape: created");
    }

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

}

工厂类的具体实现：

public class ShapeFactory {
    public static Shape getShape(String type) {
        Shape shape = null;
        if (type.equalsIgnoreCase("circle")) {
            shape = new CircleShape();
        } else if (type.equalsIgnoreCase("rect")) {
            shape = new RectShape();
        } else if (type.equalsIgnoreCase("triangle")) {
            shape = new TriangleShape();
        }
        return shape;
    }
}

在这个工厂类中通过传入不同的type可以new不同的形状，返回结果为Shape 类型，这个就是简单工厂核心的地方了。

客户端使用：

Shape shape= ShapeFactory.getShape("circle");
shape.draw();

通过给ShapeFactory传入不同的参数就实现了各种形状的绘制。

简单工厂模式的优点：只需要一个工厂创建对象，代码量少。

简单工厂模式的缺点：系统扩展困难，新增产品需要修改工厂逻辑，当产品较多时，会造成工厂逻辑过于复杂，不利于系统扩展和维护。

工厂方法模式

工厂方法模式是简单工厂的进一步深化，在工厂方法模式中，我们不再提供一个统一的工厂类来创建所有的对象，而是针对不同的对象提供不同的工厂。每个对象都有一个与之对应的工厂。

我们设计一个这样的图片加载类，它具有多个图片加载器，用来加载jpg，png，gif格式的图片，每个加载器都有一个read方法，用于读取图片。

首先完成图片加载器的设计，编写一个加载器的公共接口。

public interface Reader {
    void read();
}

各个图片加载器的实现如下：

public class JpgReader implements Reader {
    @Override
    public void read() {
        System.out.print("read jpg");
    }
}

public class PngReader implements Reader {
    @Override
    public void read() {
        System.out.print("read png");
    }
}

定义一个抽象的工厂接口ReaderFactory，通过getReader()方法返回我们的Reader 类。

public interface ReaderFactory {
    Reader getReader();
}

为每个图片加载器都提供一个工厂类，这些工厂类实现了ReaderFactory 。

public class JpgReaderFactory implements ReaderFactory {
    @Override
    public Reader getReader() {
        return new JpgReader();
    }
}

public class PngReaderFactory implements ReaderFactory {
    @Override
    public Reader getReader() {
        return new PngReader();
    }
}

public class GifReaderFactory implements ReaderFactory {
    @Override
    public Reader getReader() {
        return new GifReader();
    }
}

客户端通过子类来指定创建对应的对象。

ReaderFactory factory=new JpgReaderFactory();
Reader  reader=factory.getReader();
reader.read();

和简单工厂对比一下，最根本的区别在于，简单工厂只有一个统一的工厂类，而工厂方法是针对每个要创建的对象都会提供一个工厂类，这些工厂类都实现了一个工厂基类（本例中的ReaderFactory ）。

优点：增加新的产品类时无须修改现有系统，只需增加新产品和对应的工厂类即可。

抽象工厂模式

抽象工厂模式创建的是对象家族，也就是很多对象而不是一个对象，并且这些对象是相关的，也就是说必须一起创建出来。而工厂方法模式只是用于创建一个对象，这和抽象工厂模式有很大不同。

假设现在需要做一款跨平台的游戏，需要兼容Android，IOS两个移动操作系统，该游戏针对每个系统都设计了一套操作控制器（OperationController）和界面控制器（UIController），下面通过抽象工厂模式完成这款游戏的架构设计。

新建两个抽象产品接口。

//抽象操作控制器
public interface OperationController {
    void control();
}

//抽象界面控制器
public interface UIController {
    void display();
}

然后完成这两个系统平台的具体操作控制器和界面控制器。

//Android
public class AndroidOperationController implements OperationController {
    @Override
    public void control() {
        System.out.println("AndroidOperationController");
    }
}

public class AndroidUIController implements UIController {
    @Override
    public void display() {
        System.out.println("AndroidInterfaceController");
    }
}


//IOS
public class IosOperationController implements OperationController {
    @Override
    public void control() {
        System.out.println("IosOperationController");
    }
}

public class IosUIController implements UIController {
    @Override
    public void display() {
        System.out.println("IosInterfaceController");
    }
}

下面定义一个抽象工厂，该工厂需要可以创建OperationController和UIController

public interface SystemFactory {
    public OperationController createOperationController();
    public UIController createInterfaceController();
}

//android
public class AndroidFactory implements SystemFactory {
    @Override
    public OperationController createOperationController() {
        return new AndroidOperationController();
    }

    @Override
    public UIController createInterfaceController() {
        return new AndroidUIController();
    }
}

//IOS
public class IosFactory implements SystemFactory {
    @Override
    public OperationController createOperationController() {
        return new IosOperationController();
    }

    @Override
    public UIController createInterfaceController() {
        return new IosUIController();
    }
}

客户端调用如下：

SystemFactory mFactory;
UIController interfaceController;
OperationController operationController;

//Android
mFactory = new AndroidFactory();
//IOS
//mFactory=new IosFactory();

interfaceController = mFactory.createInterfaceController();
operationController = mFactory.createOperationController();
interfaceController.display();
operationController.control();

针对不同平台只通过创建不同的工厂对象就完成了操作和UI控制器的创建。

适用场景：

和工厂方法一样客户端不需要知道它所创建的对象的类。
需要一组对象共同完成某种功能时。并且可能存在多组对象完成不同功能的情况。
系统结构稳定，不会频繁的增加对象。（因为一旦增加就需要修改原有代码，不符合开闭原则）

模板模式

一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。

模板模式主要由抽象模板(Abstract Template)角色和具体模板(Concrete Template)角色组成。

抽象模板(Abstract Template)：定义了一个或多个抽象操作，以便让子类实现。这些抽象操作叫做基本操作，它们是一个顶级逻辑的组成步骤;定义并实现了一个模板方法。这个模板方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。
具体模板(Concrete Template)：实现父类所定义的一个或多个抽象方法，它们是一个顶级逻辑的组成步骤;每一个抽象模板角色都可以有任意多个具体模板角色与之对应，而每一个具体模板角色都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。

以游戏为例。创建一个抽象类，它的模板方法被设置为 final，这样它就不会被重写。

public abstract class Game {
    abstract void initialize();
    abstract void startPlay();
    abstract void endPlay();

    //模板
    public final void play(){
        //初始化游戏
        initialize();

        //开始游戏
        startPlay();

        //结束游戏
        endPlay();
    }
}

Football类：

public class Football extends Game {

    @Override
    void endPlay() {
        System.out.println("Football Game Finished!");
    }

    @Override
    void initialize() {
        System.out.println("Football Game Initialized! Start playing.");
    }

    @Override
    void startPlay() {
        System.out.println("Football Game Started. Enjoy the game!");
    }
}

使用Game的模板方法 play() 来演示游戏的定义方式。

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

        Game game = new Cricket();
        game.play();
        System.out.println();
        game = new Football();
        game.play();      
    }
}

模板模式优点：

封装不变部分，扩展可变部分。
提取公共代码，便于维护。
行为由父类控制，子类实现。

模板模式缺点：

每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。

策略模式

策略模式（Strategy Pattern）属于对象的行为模式。其用意是针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。

其主要目的是通过定义相似的算法，替换if else 语句写法，并且可以随时相互替换。

策略模式主要由这三个角色组成，环境角色(Context)、抽象策略角色(Strategy)和具体策略角色(ConcreteStrategy)。

环境角色(Context)：持有一个策略类的引用，提供给客户端使用。
抽象策略角色(Strategy)：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。
具体策略角色(ConcreteStrategy)：包装了相关的算法或行为。

以计算器为例，如果我们想得到两个数字相加的和，我们需要用到“+”符号，得到相减的差，需要用到“-”符号等等。虽然我们可以通过字符串比较使用if/else写成通用方法，但是计算的符号每次增加，我们就不得不加在原先的方法中进行增加相应的代码，如果后续计算方法增加、修改或删除，那么会使后续的维护变得困难。

但是在这些方法中，我们发现其基本方法是固定的，这时我们就可以通过策略模式来进行开发，可以有效避免通过if/else来进行判断，即使后续增加其他的计算规则也可灵活进行调整。

首先定义一个抽象策略角色，并拥有一个计算的方法。

interface CalculateStrategy {
    int doOperation(int num1, int num2);
}

然后再定义加减乘除这些具体策略角色并实现方法。代码如下：

class OperationAdd implements CalculateStrategy {
    @Override
    public int doOperation(int num1, int num2) {
        return num1 + num2;
    }
}

class OperationSub implements CalculateStrategy {
    @Override
    public int doOperation(int num1, int num2) {
        return num1 - num2;
    }
}

class OperationMul implements CalculateStrategy {
    @Override
    public int doOperation(int num1, int num2) {
        return num1 * num2;
    }
}

class OperationDiv implements CalculateStrategy {
    @Override
    public int doOperation(int num1, int num2) {
        return num1 / num2;
    }
}

最后在定义一个环境角色，提供一个计算的接口供客户端使用。代码如下：

class  CalculatorContext {
    private CalculateStrategy strategy;

    public CalculatorContext(CalculateStrategy strategy) {
        this.strategy = strategy;
    }

    public int executeStrategy(int num1, int num2) {
        return strategy.doOperation(num1, num2);
    }
}

测试代码如下：

public static void main(String[] args) {
    int a=4,b=2;
    CalculatorContext context = new CalculatorContext(new OperationAdd());    
    System.out.println("a + b = "+context.executeStrategy(a, b));

    CalculatorContext context2 = new CalculatorContext(new OperationSub());      
    System.out.println("a - b = "+context2.executeStrategy(a, b));

    CalculatorContext context3 = new CalculatorContext(new OperationMul());    
    System.out.println("a * b = "+context3.executeStrategy(a, b));

    CalculatorContext context4 = new CalculatorContext(new OperationDiv());    
    System.out.println("a / b = "+context4.executeStrategy(a, b));
}

策略模式优点：

扩展性好，可以在不修改对象结构的情况下，为新的算法进行添加新的类进行实现；
灵活性好，可以对算法进行自由切换；

策略模式缺点：

使用策略类变多，会增加系统的复杂度；
客户端必须知道所有的策略类才能进行调用；

使用场景：

如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为；一个系统需要动态地在几种算法中选择一种；
如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现；

责任链模式

为了避免请求发送者与多个请求处理者耦合在一起，于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。

在责任链模式中，客户只需要将请求发送到责任链上即可，无须关心请求的处理细节和请求的传递过程，请求会自动进行传递。所以责任链将请求的发送者和请求的处理者解耦了。

优点

责任链模式是一种对象行为型模式，有以下优点：

降低了对象之间的耦合度。该模式使得一个对象无须知道到底是哪一个对象处理其请求以及链的结构，发送者和接收者也无须拥有对方的明确信息。
增强了系统的可扩展性。可以根据需要增加新的请求处理类，满足开闭原则。
增强了给对象指派职责的灵活性。当工作流程发生变化，可以动态地改变链内的成员或者调动它们的次序，也可动态地新增或者删除责任。
责任链简化了对象之间的连接。每个对象只需保持一个指向其后继者的引用，不需保持其他所有处理者的引用，这避免了使用众多的 if 或者 if···else 语句。
责任分担。每个类只需要处理自己该处理的工作，不该处理的传递给下一个对象完成，明确各类的责任范围，符合类的单一职责原则。

缺点

不能保证每个请求一定被处理。由于一个请求没有明确的接收者，所以不能保证它一定会被处理，该请求可能一直传到链的末端都得不到处理。
对比较长的职责链，请求的处理可能涉及多个处理对象，系统性能将受到一定影响。
职责链建立的合理性要靠客户端来保证，增加了客户端的复杂性，可能会由于职责链的错误设置而导致系统出错，如可能会造成循环调用。

责任链模式的结构

抽象处理者（Handler）角色：定义一个处理请求的接口，包含抽象处理方法和一个后继连接。
具体处理者（Concrete Handler）角色：实现抽象处理者的处理方法，判断能否处理本次请求，如果可以处理请求则处理，否则将该请求转给它的后继者。
客户类（Client）角色：创建处理链，并向链头的具体处理者对象提交请求，它不关心处理细节和请求的传递过程。

比如要开发一个请假流程控制系统。请假一天以下的假只需要小组长同意即可；请假1天到3天的假还需要部门经理同意；请求3天到7天还需要总经理同意才行。

请假条类：

public class LeaveRequest {
    //姓名
    private String name;
    // 请假天数
    private int num;
    // 请假内容
    private String content;

    public LeaveRequest(String name, int num, String content) {
        this.name = name;
        this.num = num;
        this.content = content;
    }

    public String getName() {
        return name;
    }

    public int getNum() {
        return num;
    }

    public String getContent() {
        return content;
    }

}

处理类：

public abstract class Handler {
    protected final static int NUM_ONE = 1;
    protected final static int NUM_THREE = 3;
    protected final static int NUM_SEVEN = 7;

    //该领导处理的请假天数区间
    private int numStart;
    private int numEnd;


    //领导上还有领导
    private Handler nextHandler;

    //设置请假天数范围
    public Handler(int numStart) {
        this.numStart = numStart;
    }

    //设置请假天数范围
    public Handler(int numStart, int numEnd) {
        this.numStart = numStart;
        this.numEnd = numEnd;
    }

    //设置上级领导
    public void setNextHandler(Handler nextHandler) {
        this.nextHandler = nextHandler;
    }

    //提交请假条
    public final void submit(LeaveRequest leaveRequest) {
        if (this.numStart == 0) {
            return;
        }
        //请假天数达到领导处理要求
        if (leaveRequest.getNum() >= this.numStart) {
            this.handleLeave(leaveRequest);

            //如果还有上级 并且请假天数超过当前领导的处理范围
            if (this.nextHandler != null && leaveRequest.getNum() > numEnd) {
                //继续提交
                this.nextHandler.submit(leaveRequest);
            } else {
                System.out.println("流程结束！！！");
            }
        }
    }

    //各级领导处理请假条方法
    protected abstract void handleLeave(LeaveRequest leave);

}

小组长类：

public class GroupLeader extends Handler {
    //1-3天的假
    public GroupLeader() {
        super(Handler.NUM_ONE, Handler.NUM_THREE);
    }

    @Override
    protected void handleLeave(LeaveRequest leave) {
        System.out.println(leave.getName() + "请假" + leave.getNum() + "天，" + leave.getContent() + "!");
        System.out.println("小组长审批通过：同意！");
    }
}

部门经理类：

public class Manager extends Handler {
    //3-7天的假
    public Manager() {
        super(Handler.NUM_THREE, Handler.NUM_SEVEN);
    }

    @Override
    protected void handleLeave(LeaveRequest leave) {
        System.out.println(leave.getName() + "请假" + leave.getNum() + "天，" + leave.getContent() + "!");
        System.out.println("部门经理审批通过：同意！");
    }
}

总经理类：

public class GeneralManager extends Handler{
    //7天以上的假
    public GeneralManager() {
        super(Handler.NUM_THREE, Handler.NUM_SEVEN);
    }

    @Override
    protected void handleLeave(LeaveRequest leave) {
        System.out.println(leave.getName() + "请假" + leave.getNum() + "天，" + leave.getContent() + "!");
        System.out.println("总经理审批通过：同意！");
    }
}

测试类：

public class Client {
    public static void main(String[] args) {
        //请假条
        LeaveRequest leave = new LeaveRequest("小庄", 3, "出去旅游");

        //各位领导
        Manager manager = new Manager();
        GroupLeader groupLeader = new GroupLeader();
        GeneralManager generalManager = new GeneralManager();

        /*
         * 小组长上司是经理 经理上司是总经理
         */
        groupLeader.setNextHandler(manager);
        manager.setNextHandler(generalManager);

        //提交
        groupLeader.submit(leave);

    }
}

责任链模式的应用场景：

多个对象可以处理一个请求，但具体由哪个对象处理该请求在运行时自动确定。
可动态指定一组对象处理请求，或添加新的处理者。
需要在不明确指定请求处理者的情况下，向多个处理者中的一个提交请求。

装饰模式

装饰者模式(decorator pattern)：动态地将责任附加到对象上, 若要扩展功能, 装饰者提供了比继承更有弹性的替代方案。

装饰模式以对客户端透明的方式拓展对象的功能，客户端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不创造更多子类的情况下，将对象的功能加以扩展。

比如设置FileInputStream，先用BufferedInputStream装饰它，再用自己写的LowerCaseInputStream过滤器去装饰它。

InputStream in = new LowerCaseInputStream(new BufferedInputStream(new FileInputStream("test.txt")));

在装饰模式中的角色有：

抽象组件(Component)角色：给出一个抽象接口，以规范准备接收附加责任的对象。
具体组件(ConcreteComponent)角色：定义一个将要接收附加责任的类。
抽象装饰(Decorator)角色：持有一个组件(Component)对象的实例，并定义一个与抽象组件接口一致的接口。
具体装饰(ConcreteDecorator)角色：负责给构件对象“贴上”附加的责任。

在LOL、王者荣耀等类Dota游戏中，每次英雄升级都会附加一个额外技能点学习技能，这个就类似装饰模式为已有类动态附加额外的功能。

具体的英雄就是ConcreteComponent，技能栏就是装饰器Decorator，每个技能就是ConcreteDecorator。

新建一个接口：

public interface Hero {
    //学习技能
    void learnSkills();
}

创建接口的实现类（具体英雄盲僧）：

//ConcreteComponent 具体英雄盲僧
public class BlindMonk implements Hero {

    private String name;

    public BlindMonk(String name) {
        this.name = name;
    }

    @Override
    public void learnSkills() {
        System.out.println(name + "学习了以上技能！");
    }
}

装饰角色：

//Decorator 技能栏
public abstract class Skills implements Hero {

    //持有一个英雄对象接口
    private Hero hero;

    public Skills(Hero hero) {
        this.hero = hero;
    }

    @Override
    public void learnSkills() {
        if(hero != null)
            hero.learnSkills();
    }    
}

具体装饰角色：

//ConreteDecorator 技能：Q
public class Skill_Q extends Skills{

    private String skillName;

    public Skill_Q(Hero hero,String skillName) {
        super(hero);
        this.skillName = skillName;
    }

    @Override
    public void learnSkills() {
        System.out.println("学习了技能Q:" +skillName);
        super.learnSkills();
    }
}

//ConreteDecorator 技能：W
public class Skill_W extends Skills{

    private String skillName;

    public Skill_W(Hero hero,String skillName) {
        super(hero);
        this.skillName = skillName;
    }

    @Override
    public void learnSkills() {
        System.out.println("学习了技能W:" + skillName);
        super.learnSkills();
    }
}
//ConreteDecorator 技能：E
public class Skill_E extends Skills{

    private String skillName;

    public Skill_E(Hero hero,String skillName) {
        super(hero);
        this.skillName = skillName;
    }

    @Override
    public void learnSkills() {
        System.out.println("学习了技能E:"+skillName);
        super.learnSkills();
    }
}
//ConreteDecorator 技能：R
public class Skill_R extends Skills{    

    private String skillName;

    public Skill_R(Hero hero,String skillName) {
        super(hero);
        this.skillName = skillName;
    }

    @Override
    public void learnSkills() {
        System.out.println("学习了技能R:" +skillName );
        super.learnSkills();
    }
}

客户端：

//客户端：召唤师
public class Player {
    public static void main(String[] args) {
        //选择英雄
        Hero hero = new BlindMonk("李青");

        Skills skills = new Skills(hero);
        Skills r = new Skill_R(skills,"猛龙摆尾");
        Skills e = new Skill_E(r,"天雷破/摧筋断骨");
        Skills w = new Skill_W(e,"金钟罩/铁布衫");
        Skills q = new Skill_Q(w,"天音波/回音击");
        //学习技能
        q.learnSkills();
    }
}

适配器模式

适配器模式将现成的对象通过适配变成我们需要的接口。适配器让原本接口不兼容的类可以合作。

适配器模式有类的适配器模式和对象的适配器模式两种不同的形式。

对象适配器模式通过组合对象进行适配。

类适配器通过继承来完成适配。

适配器模式的优点：

更好的复用性。系统需要使用现有的类，而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用。
更好的扩展性。在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。

观察者模式

观察者模式（Observer），又叫发布-订阅模式（Publish/Subscribe），定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。

主题Subject

首先定义一个观察者数组，并实现增、删及通知操作。它的职责很简单，就是定义谁能观察，谁不能观察，用Vector是线程同步的，比较安全，也可以使用ArrayList，是线程异步的，但不安全。

public class Subject {

    //观察者数组
    private Vector<Observer> oVector = new Vector<>();

    //增加一个观察者
    public void addObserver(Observer observer) {
        this.oVector.add(observer);
    }

    //删除一个观察者
    public void deleteObserver(Observer observer) {
        this.oVector.remove(observer);
    }

    //通知所有观察者
    public void notifyObserver() {
        for(Observer observer : this.oVector) {
            observer.update();
        }
    }

}

抽象观察者Observer

观察者一般是一个接口，每一个实现该接口的实现类都是具体观察者。

public interface Observer {
    //更新
    public void update();
}

具体主题

继承Subject类，在这里实现具体业务，在具体项目中，该类会有很多变种。

public class ConcreteSubject extends Subject {

    //具体业务
    public void doSomething() {
        //...
        super.notifyObserver();
    }

}

具体观察者

实现Observer接口。

public class ConcreteObserver implements Observer {

    @Override
    public void update() {
        System.out.println("收到消息，进行处理");
    }

}

Client客户端

首先创建一个被观察者，然后定义一个观察者，将该被观察者添加到该观察者的观察者数组中，进行测试。

public class Client {

    public static void main(String[] args) {
        //创建一个主题
        ConcreteSubject subject = new ConcreteSubject();
        //定义一个观察者
        Observer observer = new ConcreteObserver();
        //观察
        subject.addObserver(observer);
        //开始活动
        subject.doSomething();
    }

}

观察者模式的优点

观察者和被观察者是抽象耦合的
建立了一套触发机制

观察者模式的缺点

如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间
如果观察者和观察目标间有循环依赖，可能导致系统崩溃
没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的

观察者模式的使用场景

关联行为场景
事件多级触发场景
跨系统的消息变换场景，如消息队列的处理机制

代理模式

代理模式使用代理对象完成用户请求，屏蔽用户对真实对象的访问。

代理模式一般有三种角色：

抽象（Subject）角色，该角色是真实主题和代理主题的共同接口，以便在任何可以使用真实主题的地方都可以使用代理主题。
代理（Proxy Subject）角色，也叫做委托类、代理类，该角色负责控制对真实主题的引用，负责在需要的时候创建或删除真实主题对象，并且在真实主题角色处理完毕前后做预处理和善后处理工作。
真实（Real Subject）角色：该角色也叫做被委托角色、被代理角色，是业务逻辑的具体执行者。

静态代理

静态代理：代理类在编译阶段生成，程序运行前就已经存在，在编译阶段将通知织入Java字节码中。

以租房为例，我们一般用租房软件、找中介或者找房东。这里的中介就是代理者。

首先定义一个提供了租房方法的接口。

public interface IRentHouse {
    void rentHouse();
}

定义租房的实现类

public class RentHouse implements IRentHouse {
    @Override
    public void rentHouse() {
        System.out.println("租了一间房子。。。");
    }
}

我要租房，房源都在中介手中，所以找中介

public class IntermediaryProxy implements IRentHouse {

    private IRentHouse rentHouse;

    public IntermediaryProxy(IRentHouse irentHouse){
        rentHouse = irentHouse;
    }

    @Override
    public void rentHouse() {
        System.out.println("交中介费");
        rentHouse.rentHouse();
        System.out.println("中介负责维修管理");
    }
}

这里中介也实现了租房的接口。

在main方法中测试

public class Main {

    public static void main(String[] args){
        //定义租房
        IRentHouse rentHouse = new RentHouse();
        //定义中介
        IRentHouse intermediary = new IntermediaryProxy(rentHouse);
        //中介租房
        intermediary.rentHouse();
    }
}

这就是静态代理，因为中介这个代理类已经事先写好了，只负责代理租房业务。

缺点：因为代理对象需要与目标对象实现一样的接口，所以会有很多代理类。同时，一旦接口增加方法，目标对象与代理对象都要维护。

动态代理

动态代理：代理类在程序运行时创建，在内存中临时生成一个代理对象，在运行期间对业务方法进行增强。

JDK动态代理

JDK实现代理只需要使用Proxy的newProxyInstance方法：

static Object newProxyInstance(ClassLoader loader, Class<?>[] interfaces,   InvocationHandler h )

三个入参：

ClassLoader loader：指定当前目标对象使用的类加载器
Class<?>[] interfaces：目标对象实现的接口的类型
InvocationHandler：当代理对象调用目标对象的方法时，会触发事件处理器的invoke方法()

还是以租房为例。

现在的中介不仅仅是有租房业务，同时还有卖房、家政、维修等得业务，只是我们就不能对每一个业务都增加一个代理，就要提供通用的代理方法，这就要通过动态代理来实现了。

中介的代理方法做了一下修改：

public class IntermediaryProxy implements InvocationHandler {


    private Object obj;

    public IntermediaryProxy(Object object){
        obj = object;
    }

    /**
     * 调用被代理的方法
     * @param proxy
     * @param method
     * @param args
     * @return
     * @throws Throwable
     */
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        Object result = method.invoke(this.obj, args);
        return result;
    }

}

在这里实现InvocationHandler接口，此接口是JDK提供的动态代理接口，对被代理的方法提供代理。其中invoke方法是接口InvocationHandler定义必须实现的，它完成对真实方法的调用。动态代理是根据被代理的接口生成所有的方法，也就是说给定一个接口，动态代理就会实现接口下所有的方法。通过 InvocationHandler接口，所有方法都由该Handler来进行处理，即所有被代理的方法都由 InvocationHandler接管实际的处理任务。

这里增加一个卖房的业务，代码和租房代码类似。

main方法测试：

public static void main(String[] args){

    IRentHouse rentHouse = new RentHouse();
    //定义一个handler
    InvocationHandler handler = new IntermediaryProxy(rentHouse);
    //获得类的class loader
    ClassLoader cl = rentHouse.getClass().getClassLoader();
    //动态产生一个代理者
    IRentHouse proxy = (IRentHouse) Proxy.newProxyInstance(cl, new Class[]{IRentHouse.class}, handler);
    proxy.rentHouse();

    ISellHouse sellHouse = new SellHouse();
    InvocationHandler handler1 = new IntermediaryProxy(sellHouse);
    ClassLoader classLoader = sellHouse.getClass().getClassLoader();
    ISellHouse proxy1 = (ISellHouse) Proxy.newProxyInstance(classLoader, new Class[]{ISellHouse.class}, handler1);
    proxy1.sellHouse();

}

在main方法中我们用到了Proxy这个类的方法：

public static Object newProxyInstance(ClassLoader loader,
                                          Class<?>[] interfaces,
                                          InvocationHandler h)

InvocationHandler 是一个接口，每个代理的实例都有一个与之关联的 InvocationHandler 实现类，如果代理的方法被调用，那么代理便会通知和转发给内部的 InvocationHandler 实现类，由它决定处理。

public interface InvocationHandler {

    public Object invoke(Object proxy, Method method, Object[] args)
        throws Throwable;
}

InvocationHandler 内部只是一个 invoke() 方法，正是这个方法决定了怎么样处理代理传递过来的方法调用。

因为，Proxy 动态产生的代理会调用 InvocationHandler 实现类，所以 InvocationHandler 是实际执行者。

建造者模式

Builder 模式中文叫作建造者模式，又叫生成器模式，它属于对象创建型模式，是将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。

在建造者模式中，有如下４种角色：

Product：产品角色
Builder：抽象建造者，定义产品接口
ConcreteBuilder：具体建造者，实现Builder定义的接口，并且返回组装好的产品
Director：指挥者，属于这里面的老大，你需要生产什么产品都直接找它。

我们就以家装为例，一起来学习了解一下建造者模式。

家装对象类：

/**
 * 家装对象类
 */
public class House {
    // 买家电
    private String jiadian;

    // 买地板
    private String diban;
    // 买油漆
    private String youqi;

    public String getJiadian() {
        return jiadian;
    }

    public void setJiadian(String jiadian) {
        this.jiadian = jiadian;
    }

    public String getDiban() {
        return diban;
    }

    public void setDiban(String diban) {
        this.diban = diban;
    }

    public String getYouqi() {
        return youqi;
    }

    public void setYouqi(String youqi) {
        this.youqi = youqi;
    }

    @Override
    public String toString() {
        return "House{" +
            "jiadian='" + jiadian + '\'' +
            ", diban='" + diban + '\'' +
            ", youqi='" + youqi + '\'' +
            '}';
    }
}

抽象建造者 Builder 类：

/**
 * 抽象建造者
 */
public interface HouseBuilder {
    // 买家电
    void doJiadian();
    // 买地板
    void doDiBan();
    // 买油漆
    void doYouqi();

    House getHouse();
}

具体建造者－简装建造者类

/**
 * 简装创建者
 */
public class JianzhuangBuilder implements HouseBuilder {

    private House house = new House();

    @Override
    public void doJiadian() {
        house.setJiadian("简单家电就好");
    }

    @Override
    public void doDiBan() {
        house.setDiban("普通地板");
    }

    @Override
    public void doYouqi() {
        house.setYouqi("污染较小的油漆就行");
    }

    @Override
    public House getHouse() {
        return house;
    }
}

具体建造者－精装建造者类

/**
 * 精装创建者
 */
public class JingzhuangBuilder implements HouseBuilder {

    private House house = new House();

    @Override
    public void doJiadian() {
        house.setJiadian("二话不说，最好的");
    }

    @Override
    public void doDiBan() {
        house.setDiban("二话不说，实木地板");
    }

    @Override
    public void doYouqi() {
        house.setYouqi("二话不说，给我来0污染的");
    }

    @Override
    public House getHouse() {
        return house;
    }
}

指挥官－家装公司类

/**
 * 家装公司，只需要告诉他精装还是简装
 */
public class HouseDirector {

    public House builder(HouseBuilder houseBuilder){
        houseBuilder.doDiBan();
        houseBuilder.doJiadian();
        houseBuilder.doYouqi();
        return houseBuilder.getHouse();
    }
}

测试：

public class App {
    public static void main(String[] args) {
        house();
    }

    public static void house(){
        HouseDirector houseDirector = new HouseDirector();
        // 简装
        JianzhuangBuilder jianzhuangBuilder = new JianzhuangBuilder();
        System.out.println("我要简装");
        System.out.println(houseDirector.builder(jianzhuangBuilder));

        // 精装
        JingzhuangBuilder jingzhuangBuilder = new jingzhuangBuilder();
        System.out.println("我要精装");
        System.out.println(houseDirector.builder(jingzhuangBuilder));

    }
}

我们以家装为例，实现了两个具体的建造者，一个简装建造者、一个精装建造者。我们只需要告诉家装公司，我是需要简装还是精装，它会去帮我们安排，我不需要知道里面具体的细节。

在日常开发中，你是不是会经常看到下面这种代码：

return new Docket(DocumentationType.SWAGGER_2)
    .apiInfo(apiInfo())
    .select()
    .apis(RequestHandlerSelectors.basePackage("com.curry.springbootswagger.controller"))
    .paths(PathSelectors.any())
    .build();

是不是很优美？学会了 Builder 模式之后，你也可以通过这种方式进行对象构建。它是通过变种的 Builder 模式实现的。先不解释了，我们先用 Builder 模式来实现跟上述的对象构建，使用学生类为例。

学生对象代码：

public class Student {

    private String name;

    private int age;

    private int num;

    private String email;

    // 提供一个静态builder方法
    public static Student.Builder builder() {
        return new Student.Builder();
    }
    // 外部调用builder类的属性接口进行设值。
    public static class Builder{
        private String name;

        private int age;

        private int num;

        private String email;

        public Builder name(String name) {
            this.name = name;
            return this;
        }

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

        public Builder num(int num) {
            this.num = num;
            return this;
        }

        public Builder email(String email) {
            this.email = email;
            return this;
        }

        public Student build() {
            // 将builder对象传入到学生构造函数
            return new Student(this);
        }
    }
    // 私有化构造器
    private Student(Builder builder) {
        name = builder.name;
        age = builder.age;
        num = builder.num;
        email = builder.email;
    }

    @Override
    public String toString() {
        return "Student{" +
            "name='" + name + '\'' +
            ", age=" + age +
            ", num=" + num +
            ", email='" + email + '\'' +
            '}';
    }
}

可以看到，变种 Builder 模式包括以下内容：

在要构建的类内部创建一个静态内部类 Builder
静态内部类的参数与构建类一致
构建类的构造参数是静态内部类，使用静态内部类的变量一一赋值给构建类
静态内部类提供参数的 setter 方法，并且返回值是当前 Builder 对象
最终提供一个 build 方法构建一个构建类的对象，参数是当前 Builder 对象

可能你会说，这种写法实现太麻烦了，确实需要我们写很多额外的代码，好在前辈们已经开发出了lombok来拯救我们，我们只需要引入lombok插件，然后在实体类上添加@Builder注解，你就可以使用 Builder 模式构建对象了。

建造者模式的优缺点

优点：

在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象
每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象
可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程
增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合“开闭原则”。

缺点：

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

posted @ 2023-04-05 21:07 残城碎梦阅读(36) 评论(0) 编辑收藏举报

刷新页面返回顶部

登录后才能查看或发表评论，立即登录或者逛逛博客园首页

相关博文：

· 【◉设计模式】动态代理详解

· 适配器模式

· 你管这叫代理模式(Proxy Pattern)

· 设计模式——行为型模式

· 设计模式笔记

历史上的今天：
2022-04-05 【Windows/Linux】xxl-job部署及使用
2022-04-05 【Windows】部署ELK
2022-04-05 【Windows/Linux】安装Sentinel
2022-04-05 【Windows】安装Zipkin
2022-04-05 【Windows】安装skywalking
2022-04-05 【Windows】Redis集群部署
2022-04-05 【Windows】Redis单机部署

残城碎梦