在软件开发中，我们通常会为对象定义状态来适应不同的场景。在传统程序中，我们通常会定义状态变量来进行不同状态的切换，再通过if else语句来进行逻辑的判断，从而使不同状态的执行行为发生改变。但这样做会造成软件的臃肿和难以维护。在引入新的状态时，需要增加新的条件判断语句，这违背了“开闭原则”。本文将使用设计模式之状态模式来解决这个问题。

状态模式 #

 状态模式的定义 

> 状态模式（State）：对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为。

在状态模式中，我们不将“状态”简单地定义为变量来进行处理，而是将其定义为类，用类来表示状态。这可能是个抽象的概念，下文我们将使用实例来进行详细讲解。

 状态模式的结构 

- 上下文/环境（Context）：它维护了一个当前的状态，并提供了供开发者调用的接口，负责具体状态的切换。
- 抽象状态（State）：接口，定义了上下文对象中状态对应的方法。
- 具体状态（ConcreteState）：实现抽象状态接口中定义的所有方法。

 状态模式的具体应用场景 

- 聊天软件中的不同状态：如在线、离线、忙碌状态
- 状态机：操作系统往往需要管理不同的状态。例如安卓操作系统中就有基于状态树的决策机制。具体实现过程不是本篇的重点，感兴趣可以自行查阅操作系统的资料。

 示例 

本文，我们来实现一个商城订单的四种不同状态：分别是待付款，待发货，待收货和退款中状态。

不同状态有着不同的处理逻辑。

- 待付款状态下，系统会提示用户尽快付款。
- 待发货状态下，系统会提示商家尽快发货。
- 待收获状态下，系统会为用户推送物流信息。

我们使用状态模式处理这个需求。

下面我们开始编写具体代码。

首先我们先来定义一个抽象状态（State）：

State.java

`java
package com.yeliheng.state;

/
 * 抽象状态
 */
public abstract class State {
    public abstract void handle(Context context);
}
`

在抽象状态类中，我们定义了一个抽象方法handle() 用于处理传入的上下文对象。

接着，我们可以定义一个Context类。

Context.java

`java
package com.yeliheng.state;

public class Context {

    private State state;

    public Context() {
        this.state = new PendingPaymentState();
    }

    public State getState() {
        return state;
    }

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

    public void handle() {
        state.handle(this);
    }
}
`
上下文对象中，我们定义了一个状态变量State，并提供相应的setter getter方法。方便后续具体状态设置即将切换的下一个状态。并且我们初始化初状态为PendingPaymentState即待付款状态。

我们开始定义具体的状态类。

PendingPaymentState.java

`java
package com.yeliheng.state;

public class PendingPaymentState extends State{
    @Override
    public void handle(Context context) {
        System.out.println("[订单待付款-买家中心] 您有一笔订单等待付款。");
        context.setState(new PendingDeliveryState());
    }
}
`
在待付款状态中，系统会输出用户提示，并将下一个状态指定给待发货状态。代码实现很简单，另外两个具体状态类同理。

PendingReceiptState.java

`java

package com.yeliheng.state;

public class PendingReceiptState extends State{
    @Override
    public void handle(Context context) {
        System.out.println("[订单待收货-买家中心] 卖家已发货，当前物流在：XXX省XXX市");
    }
}
`

PendingDeliveryState.java

`java
package com.yeliheng.state;

public class PendingDeliveryState extends State{
    @Override
    public void handle(Context context) {
        System.out.println("[订单待发货-卖家中心] 买家已付款，请尽快发货。");
        context.setState(new PendingReceiptState());
    }
}
`

最后我们可以在main函数中调用此程序，观察输出结果。

Main.java

`java
package com.yeliheng.state;

public class Main {
    public static void main(String[] args) {
        Context context = new Context(); //注册上下文
        //买家付款
        context.handle();
        //卖家发货
        context.handle();
        //买家收货
        context.handle();

    }
}
`

在Main类中，我们初始化了一个上下文类，并调用了三次handle方法，分别模拟了三种订单状态。

最终程序的输出结果如下图所示：

!output.png

在状态模式的应用中，我们可以发现，状态变量被不同的类代替了。并且，原先臃肿的if else逻辑被状态所替代，统一交由上下文（Context）类进行管理，程序变得更加具有条理性，这有助于项目的拓展。

 状态模式的优缺点 

 优点 

- 将状态进行封装有利于减少对象间的相互依赖。
- 状态类的职责明确，符合类的“单一职责”原则。
- 状态模式结构清晰，有利于增加项目的可拓展性，降低类之间的耦合。

 缺点 

- 过度使用状态模式会造成状态类的大规模增长，提升系统的维护难度。
- 状态模式有背开闭原则。增加新的状态，必须将管理状态的上下文类进行修改才能达到目的。

总结 #

使用状态模式能够有效减少复杂的判断逻辑，增加程序的可维护性。本例通过商城中订单状态的切换来详解状态模式。

本例的完整源代码参见：Github

状态模式属于行为型模式。本文将以Java为例，带你重温GoF设计模式之状态模式，并深入理解状态模式及其应用场景。

Java设计模式再相识 (十七)——状态模式

责任链顾名思义，将责任在一个连续的链条上进行传播。在现实中，一个事情往往需要多个对象进行处理。例如公司中的一个请求，往往需要从下往上层层申报，层层审核。这就是一种责任链的体现。对于这个审核流程，每个审核者只负责处理自己职责范围内的请求，对于超出职责或权限的请求，该审核者只能将其转交给另外的或比自己更加高级的审核者进行处理。在软件开发中亦是如此。使用责任链模式处理请求能够更加清晰职责，在需要新的审核者加入时，无需改动系统的具体逻辑。

责任链模式 #

责任链模式的定义：责任链模式（Chain of Responsibility）又叫职责链模式，它可以解耦请求者和处理者的关联关系，将双方的责任进行分离，成为独立的可复用的组件。并且在有请求发生时，责任可沿着请求进行传播，直到有合适的处理者为止。在责任链模式中，开发者只需要将请求发送到责任链上，该请求自然会沿着“链”进行传播，开发者无需关心具体的处理细节以及责任链上请求的传播过程。

 责任链模式的结构 

- 抽象处理者（Handler）：抽象处理者定义一个处理请求的接口，并且包含“下一个请求者是谁”的定义，如果该抽象请求者无法处理请求，它会将请求转交给“下一个处理者”，直到有合适的处理者能够处理请求。
- 具体处理者（ConcreteHandler）：具体处理者实现了抽象处理者中的处理方法。
- 请求者（Client）：请求者能够向具体处理者发送请求，它不用关心具体的处理细节以及请求是如何传播的。

 责任链模式的具体应用场景 

- Servlet的Filter：过滤器支持定义一系列链式过滤器，将请求一层层进行过滤。这个功能就可以使用责任链模式进行实现。
- 权限管理：高于某项权限的请求需要更高的角色进行处理，这个场景也适合使用责任链模式实现。

 示例 

在本文示例中，我们使用责任链模式实现一个教务系统请假审批系统。

学生请假2天以内，辅导员可以进行线上审批。若请假时间超过2天，但小于等于7天，需系主任审批。若请假时间大于7天，需校学工处审批。我们使用责任链模式来实现这个流程。

首先，我们先定义一个抽象处理者。抽象处理者中含有一个处理者对象，用来设置下一个处理者。

Handler.java

`java
package com.yeliheng.responsibility;

/
 * 抽象处理者
 */
public abstract class Handler {

    private Handler nextHandler;

    public Handler getNextHandler() {
        return nextHandler;
    }

    public void setNextHandler(Handler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public abstract void handleRequest(int days);
}
`

在抽象处理者中，我们提供“下一个处理者的set get方法”，并且定义一个抽象方法handleRequest()以供具体处理者实现。

接下来，我们进入到具体的请假审批流程。开始编写具体的请假审批处理者类。

首先是辅导员类：

Counselor.java

`java
package com.yeliheng.responsibility;

public class Counselor extends Handler{
    @Override
    public void handleRequest(int days) {
        if(days <= 2) {
            System.out.println("[辅导员] 请假时间: " + days + "天 状态：批准");
        } else {
            if(getNextHandler() != null)
                getNextHandler().handleRequest(days);
            else System.out.println("无法处理此请求，原因：没有合适的处理器");
        }
    }
}
`

辅导员类中判断了学生的请假天数是否小于两天，如果小于两天则直接批准，否则转交该请求给下一个处理者进行处理。

下一个处理者：系主任。

DepartmentHead.java

`
package com.yeliheng.responsibility;

public class DepartmentHead extends Handler{
    @Override
    public void handleRequest(int days) {
        if(days <= 7) {
            System.out.println("[系主任] 请假时间: " + days + "天 状态：批准");
        } else {
            if(getNextHandler() != null)
                getNextHandler().handleRequest(days);
            else System.out.println("无法处理此请求，原因：没有合适的处理器");
        }
    }
}
`

学工处

StudentWorkOffice.java

`java
package com.yeliheng.responsibility;

public class StudentWorkOffice extends Handler{
    @Override
    public void handleRequest(int days) {
       System.out.println("[学工处] 请假时间: " + days + "天 状态：批准");
    }
}
`

系主任与学工处的实现逻辑和辅导员处理者类完全相同。

定义完三个具体的处理者类，我们可以开始将其串联成一个责任链，并开始发送请求，让系统根据具体逻辑对请求选择合适的处理者进行处理。

请求者类：Main.java

`java

package com.yeliheng.responsibility;

public class Main {
    public static void main(String[] args) {
        //注册处理者
        Handler counselor = new Counselor();
        Handler departmentHead = new DepartmentHead();
        Handler studentWorkOffice = new StudentWorkOffice();

        //设置责任链
        counselor.setNextHandler(departmentHead);
        counselor.setNextHandler(studentWorkOffice);

        counselor.handleRequest(5);
    }
}

`

在请求者类（即Main类）中，我们首先注册了处理者，并通过具体处理者提供的setter方法来设置下一个处理者。当具体处理者本身无法处理该请求时，就会转交给下一个处理者进行处理。最后我们调用handleRequest()方法将请求发送到责任链上。可以看到最终的输出结果如下：

!output.png

最终，请假5天这个请求被学工处处理者类进行拦截并处理，输出相关提示。

使用职责链模式实现这个需求，当我们需要增加更多的审批流程时，就可以直接引入新的处理者类即可。

 责任链模式的优缺点 

 优点 

- 降低了请求者与处理者之间的耦合度，请求者无需关心请求是怎么被处理的以及被传播到了链上的哪个位置。
- 责任链模式符合开闭原则，在需要新增流程时，只需要根据需求增加处理者类。
- 责任链模式将责任具体细分，让每个类只需要处理好自己的工作，对于无法处理的工作，移交给其它类进行完成，符合类的单一职责原则。

 缺点 

- 过度使用会导致具体处理者类的大规模增长，并造成责任链过长而维护困难的问题。
- 过长的责任链可能会导致系统性能开销增加，系统需要创建并管理更多的对象。
- 责任链的错误设置会导致责任之间的循环调用。

总结 #

合理地使用责任链模式有利于系统职责的管理以及处理和请求间的解耦。本文通过教务系统学生请假审批系统的示例讲解责任链模式。

本文示例的完整源代码参见：Github

责任链模式属于行为型模式。本文将以Java为例，带你重温GoF设计模式之责任链模式，并深入理解责任链模式及其应用场景。

Java设计模式再相识 (十六)——责任链模式

命令即Command，是我们在计算机中经常听到的词汇，命令能够让计算机明确自己的职责。现实生活中，命令模式的例子有很多，例如电视遥控器发送的红外码就可以理解成命令模式，遥控器向电视发送请求，电视根据具体请求进行处理。这就是典型的命令模式解耦的例子。

命令模式 #

命令模式（Command）的定义：将发送命令者封装成对象（类比电视遥控器），使发送请求的职责与处理请求的职责分离，即解耦，使两者通过命令进行通讯。这样，当需要管理这些对象的工作情况，就可以直接管理这些命令实例的集合，而无需修改具体的处理逻辑。命令模式能够方便对象之间的调用，提高系统的可拓展性。

 命令模式的结构 

命令模式主要包含以下结构：

- 抽象命令（Command）：定义了命令的接口和执行命令的抽象函数execute()。
- 具体命令（ConcreteCommand）：实现了抽象命令中的所有方法，并管理一个接收者（Receiver）对象，通过调用接收者（Receiver）的功能来完成命令的具体操作。
- 接收者（Receiver）：接收者负责接收并执行命令的具体操作，是业务逻辑的处理类。
- 调用者（Invoker）：调用者即发送请求的类，它管理着命令对象，并通过调用命令对象来执行请求，请注意，它不能直接访问接收者。

 命令模式的实际应用场景 

- 与硬件的串口通讯：在于硬件进行串口通信时，常常会有大量命令需要传输，如果使用if else语句进行判断后传输给硬件，会造成代码杂乱无章，难以拓展。使用命令模式将重要指令进行封装，能够将命令的发送和处理进行逻辑分离，有利于系统的解耦。
- 复杂文本编辑器的操作：文本编辑器通常需要各种功能，例如最基本的保存、复制、粘贴操作。如果体量很小，我们当然无需使用命令模式来增加系统的复杂度。但通常实际项目的体量往往比我们设想的大得多，所以我们需要提前考虑项目的拓展。例如文本编辑器还有撤销、重做等功能。这个时候使用命令模式就是必要的。

> 注：在使用命令模式时，我们还可以将一系列命令以java.util.List即列表的形式进行保存，这样我们还可以轻松维护工作的历史记录，只需要维护List实例即可。在需要执行历史命令时，只需要从实例列表中取出。

 示例 

在本文示例中，我们将模拟使用命令模式实现一个股票交易买卖Demo。股票的操作有许多种，Demo实现股票的买和卖两种操作，使用命令模式完成，方便后续其他操作模式的拓展。

首先，我们创建一个抽象命令接口。

Order.java

`java
package com.yeliheng.command;

/
 * 抽象命令
 */
public interface Order {
    void execute();
}

`

在抽象命令中，具有一个execute()方法，待会的具体命令将实现这个execute()方法。

接着，我们需要定义一个命令的接收者，即负责处理命令的具体逻辑操作。

StockCommandReceiver.java

`java
package com.yeliheng.command;

/
 * 命令接收者，处理具体的买卖逻辑
 */
public class StockCommandReceiver {

    private final String stockCode = "123456"; //股票代码

    private final int quantity = 100; //买入数量

    public void buy() {
        System.out.println("[买入] 股票代码: " + stockCode + " 数量(股): " + quantity);
    }

    public void sell() {
        System.out.println("[卖出] 股票代码: " + stockCode + " 数量(股): " + quantity);
    }
}
`

在这个类中，我们定义了两种操作的方法，分别是buy()和sell()。在两个方法中分别输出股票代码和股票数量。

然后我们就可以来实现具体命令了。

BuyCommand.java

`java
package com.yeliheng.command;

/
 * 具体命令
 */
public class BuyCommand implements Order{

    private StockCommandReceiver receiver;

    public BuyCommand(StockCommandReceiver receiver) {
        this.receiver = receiver;
    }

    @Override
    public void execute() {
        receiver.buy();
    }
}
`
BuyCommand类实现了Order订单的execute()方法，并且管理了一个命令接收者实例，方便调用者Invoker进行调用。

SellCommand与BuyCommand同理，具体代码如下：

SellCommand.java

`java
package com.yeliheng.command;

/
 * 具体命令
 */
public class SellCommand implements Order{

    private StockCommandReceiver receiver;

    public SellCommand(StockCommandReceiver receiver) {
        this.receiver = receiver;
    }

    @Override
    public void execute() {
        receiver.sell();
    }
}
`

最后，我们要实现一个命令的调用者即Invoker类，该类中含有下单和处理订单的具体逻辑。并管理了一个命令列表，方便记录历史。

Invoker.java

`java
package com.yeliheng.command;

import java.util.ArrayList;
import java.util.List;

/
 * 调用者
 */
public class Invoker {

    private List<Order> orderList = new ArrayList<>();

    //下单
    public void takeOrder(Order order) {
        orderList.add(order);
    }

    //处理订单
    public void handleOrders() {
        for(Order order : orderList) {
            order.execute();
        }
        orderList.clear();
    }

}
`
在Invoker类中，我们实现了两个方法，分别是takeOrder()和handleOrders()。takeOrder()方法会将所有订单加入到订单列表中。而handleOrders()方法将遍历所有订单，负责请求具体命令，达到订单处理的效果。

完成了命令模式的基本结构后，我们在main函数中进行使用：

Main.java

`java
package com.yeliheng.command;

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

        //注册接收者
        StockCommandReceiver receiver = new StockCommandReceiver();
        //注册命令
        BuyCommand buyCommand = new BuyCommand(receiver);
        SellCommand sellCommand = new SellCommand(receiver);

        //下单
        Invoker invoker = new Invoker();
        invoker.takeOrder(buyCommand);
        invoker.takeOrder(sellCommand);

        //处理订单
        invoker.handleOrders();
    }
}
`
在Main类中，我们首先实例化了一个接受者，再实例化具体命令，将具体命令交付给调用者实例进行管理，并执行具体业务逻辑。

最终程序的输出结果如下图所示：

!output.png

这样就完成了一个完整命令模式的示例。

 命令模式的优缺点 

 优点 

- 命令模式通过抽象接口来降低系统的耦合度。在命令的发送与具体业务的执行上进行了分离，有利于系统的解耦和后期的拓展。当有具体命令产生时，只需要增加新的具体命令类即可，无需修改命令处理的具体代码，符合开闭原则。
- 可与多种设计模式结合使用，实现强大的事件处理系统。
> 注：命令也可认为是一种特殊的事件（event），合理使用命令模式能够很好地实践“事件驱动编程”的思想。

 缺点 

- 过度使用命令模式可能会造成具体命令类大幅增长，从而提升系统的复杂度与维护难度。

总结 #

本文通过股票交易系统示例进行命令模式的讲解。命令模式在Web开发中可能用得并不多，但作为一个基础的设计模式，我们也必须熟练掌握。它在底层框架上和客户端上的应用较为广泛，掌握命令模式有助于深入理解开源框架。

本文示例的完整源代码参见：Github

命令模式属于行为型模式。本文将以Java为例，带你重温GoF设计模式之命令模式，并深入理解命令模式及其应用场景。

Java设计模式再相识 (十五)——命令模式

策略（Strategy）这个词在不同领域都十分重要，在军事领域，策略关系到行军作战的方法，而在软件开发中，使用合适的策略能让我们的软件更加易于维护。我们常常能遇到某个功能存在多种不同的解决策略的问题。例如排序算法有冒泡排序、选择排序、插入排序、快速排序等方法可供选择。这就可以用到策略模式将算法封装成一个个的策略供使用者调用。策略模式可以整体地替换问题的实现部分，从而更加灵活地解决问题。

策略模式 #

策略模式（Strategy）的定义：定义一系列算法，将每个算法进行封装，使其能够灵活替换。当算法变化时，使用者无需更改系统的内部实现，这就是策略模式。策略模式属于行为型模式，在实际项目中应用较为广泛。

在合适的场景使用策略模式能够大量减少if else的产生，能够让你的项目具备更加良好的拓展性和可读性。

 策略模式的结构 

1. 抽象策略（Strategy）：定义一个公共接口，不同策略方法可以实现这个接口。同时这个接口将被上下文（Context）类进行调用，以决策不同算法模型。
2. 具体策略（ConcreteStrategy）：实现了抽象策略中定义的接口，提供具体实现。
3. 上下文（Context）：上下文类即环境类，它管理一个策略类（Strategy）的引用，客户端将调用Context提供的方法以访问策略模式。

 策略模式的实际应用场景 

- 支付场景：一个应用同时支持微信支付、支付宝支付、银行卡支付...这类场景可以使用策略模式实现。
- 生成唯一ID的场景：如UUID生成、雪花算法、用户Token生成...
- 购物时优惠券的发放：购物时通常优惠券会使用多种方式进行发放，最常见的就是直减优惠，也有满减优惠或者直接打折的方案。

在以上场景中，如果开发者都选择使用if else来判断用户选择的类型，那么程序将臃肿并且难以维护。所以使用策略模式能够很好地解决这些问题。

示例 #

接下来，我们以购物的优惠券发放作为例子详细讲解策略模式的实现。在本例中，我们将定义三种优惠券：直减优惠券，满减优惠券，打折优惠券。用户可以自行选择使用哪种优惠券进行购物。

首先，我们定义一个抽象策略类。抽象策略类中包含一个打折方法，以供具体策略类实现和上下文进行管理。

Strategy.java

`java
package com.yeliheng.strategy;

/
 * 抽象策略
 */
public interface Strategy {
    public long discount(long price); // 策略方法
}
`

接着我们定义三个具体策略类，分别是直减策略、满减策略、折扣策略。

直减策略类：

MinusStrategy.java

`java
package com.yeliheng.strategy;

/
 * 直减策略
 */
public class MinusDiscount implements Strategy{

    private final long amount = 100; // 直减100元

    @Override
    public long discount(long price) {
        return price - amount;
    }
}
`
直减策略类直接减去100元，返回最终价格。

满减策略类：

FullReductionDiscount.java

`java
package com.yeliheng.strategy;

/
 * 满减策略
 */
public class FullReductionDiscount implements Strategy{

    private final long count = 1000; //满1000

    private final long amount = 100; //满减金额

    @Override
    public long discount(long price) {

        if(price > count) {
            return price - amount;
        } else {
           return price;
        }
    }
}
`

满减策略类中，对金额进行判断，若金额大于设定的1000元门槛，则减去满减金额100元，并返回最终价格。

折扣策略类：

BucklingDiscount.java

`java
package com.yeliheng.strategy;

/
 * 折扣策略
 */
public class BucklingDiscount implements Strategy{

    private final long discount = 8;

    //为了演示简单，直接省去小数，使用long类型。实际项目切忌这样使用。
    @Override
    public long discount(long price) {
        return (long) (price  discount  0.1);
    }
}
`

折扣策略类直接返回原价的8折。

完成了抽象策略类和具体策略类，我们定义Context类，即上下文类来对我们的策略环境进行管理。

Context.java

`java
package com.yeliheng.strategy;

public class Context {

    private Strategy strategy;

    public Strategy getStrategy() {
        return strategy;
    }

    public void setStrategy(Strategy strategy) {
        this.strategy = strategy;
    }

    public void discount(long price) {
        System.out.println("折后价格：" + strategy.discount(price));
    }
}
`

在Context类中，提供了Strategy对象的set get 方法，并定义了discount打折方法，输出具体策略类计算后的价格。

最后，我们就可以在main函数中使用写好的策略模式了。

Main.java

`java
package com.yeliheng.strategy;

public class Main {

    private static final long price = 2000; // 商品价格

    public static void main(String[] args) {

        Context context = new Context();

        System.out.println("[直减策略] 商品原价：" + price);
        Strategy strategy = new MinusDiscount();
        context.setStrategy(strategy);
        context.discount(price);

        System.out.println("-----------------");

        System.out.println("[满减策略] 商品原价：" + price);
        strategy = new FullReductionDiscount();
        context.setStrategy(strategy);
        context.discount(price);

        System.out.println("-----------------");

        System.out.println("[折扣策略] 商品原价：" + price);
        strategy = new BucklingDiscount();
        context.setStrategy(strategy);
        context.discount(price);
    }
}
`

在Main类中，我们依次对三种商品优惠券策略进行调用，运行结果如下图所示：

!output.png

三种策略均正确输出。

在本例中，我们使用策略模式减少了if else的调用，使代码的逻辑更加清晰。什么时候选择什么策略，不再需要通过一堆逻辑判断语句，而是通过策略类交给一个上下文类来进行统一地管理。

 策略模式的优缺点 

 优点 

- 使用策略模式能大大减少多重条件语句的使用，优化逻辑结构，提升项目的可维护性。
- 策略模式提供一系列可复用的解决方法，能够减少重复代码的产生。
- 策略模式遵循开闭原则，能够在不修改原来代码的情况下增加新的策略。
- 策略模式能够灵活应对复杂算法场景下产生的逻辑问题。
- 策略模式使用一个Context上下文类进行策略环境的管理，有利于定义和实现的分离。

 缺点 

- 过度使用策略模式会造成策略类的增长，增加系统复杂度。

总结 #

策略模式是一种使用广泛的设计模式之一，正确理解和使用策略模式能够提升系统的可拓展性和可维护性。本文通过购物优惠券的应用示例详细讲解策略模式的应用。

本文示例的完整源代码参见：Github

策略模式属于行为型模式，策略模式在实际项目应用较多。本文将以Java为例，带你重温GoF设计模式之策略模式，并深入理解策略模式及其应用场景。

Java设计模式再相识 (十四)——策略模式

模板顾名思义就是已经按照固定格式进行总结的一种结构形式。生活中，制造瓷器的过程就是一种模板的体现。制造陶瓷要先制作模具，然后再使用不同颜色的陶土，在模具中炼制，就可以炼制出形状一致，但花色不同的瓷器。这个生活中的例子就是模板方法模式的一个类比。在模板方法模式中，我们也是定义一系列操作的步骤，对于暂时无法确定的步骤，就交给子类进行实现。这样，子类就能够通过更加完善的步骤生成对象。

模板方法模式 #

模板方法模式（Template Method）的定义：定义一个操作中的算法“骨架”，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法模式在实际开发中的应用场景并没有很多，主要是因为我们一般不在抽象类中定义逻辑行为。而这个设计模式在抽象类中定义逻辑行为的执行顺序。

模板方法模式的结构 #

模板方法模式包含以下结构：

- 抽象模板（AbstractClass）：抽象模板定义算法的“骨架”，它实现了模板方法，也声明了在模板方法中所使用到的抽象方法。
- 具体模板（ConcreteClass）：具体模板实现抽象模板提供的抽象方法。

模板方法的实际应用场景 #

- 计算具有复杂数学属性的对象：例如加密算法
- 具有强步骤性的场景：例如签署电子协议，协议可能会经常改变，我们就可以将经常修改的协议抽象为模板。

示例 #

我们来实现一个应用协议的签署流程。假设一个应用的协议需要签署三个部分：1）应用隐私协议。2）用户操作协议。3）应用免责声明。我们使用模板方法来实现这个协议的签署。

首先，我们定义一个协议的抽象模板。抽象模板，包含签署的所有协议信息，并提供一个抽象方法以供子类扩展。

Policy.java

`java
package com.yeliheng.templatemethod;

/
 * 抽象模板
 */
public abstract class Policy {
    public void TemplateMethod() {
        agreePrivacyPolicy();
        agreeOperationPolicy();
        disclaimer();
        if(agreeResult()) {
            System.out.println("签署成功!");
        }else {
            System.out.println("签署失败!");
        }
    }

    //隐私协议
    public void agreePrivacyPolicy() {
        System.out.println("您正在签署[隐私协议]，以下是协议内容：（1）...（2）...（3）...");
    }

    //操作协议
    public void agreeOperationPolicy() {
        System.out.println("您正在签署[操作协议]，以下是协议内容：（1）...（2）...（3）...");
    }

    //应用免责声明
    public void disclaimer() {
        System.out.println("[免责声明]: （1）...（2）...（3）...");
    }

    public abstract boolean agreeResult();

}
`

抽象模板中，我们定义了签署协议的具体步骤，并定义TemplateMethod()方法来将步骤按顺序执行。当agreeResult()方法返回值为true时，我们则认为协议签署成功。

接下来，我们来拓展子类，在子类中写入签署协议的具体操作。

Sign.java

`java
package com.yeliheng.templatemethod;

/
 * 签署协议
 */
public class Sign extends Policy{
    @Override
    public boolean agreeResult() {
        //同意所有协议
        return true;
    }
}
`
Sign类即我们的具体模板类。在Sign类中，我们进行了协议的签署，为了演示方便，我们直接让agreeResult()返回true以代表协议的成功签署。

最后我们执行程序，看看最终的输出结果。

最终输出结果如下图所示：

!output.png

 模板方法模式的优缺点 

 优点 

- 模板方法模式只封装了不变的部分，可变的部分以抽象方法的方式提供，方便扩展。
- 模板方法模式符合开闭原则，因为部分方法由子类进行实现，子类可通过扩展方式增加功能。

 缺点 

- 过度使用模板方法模式会造成子类数量的大量增长，提升系统复杂度。

总结 #

模板方法模式能够将可变的，不确定的过程交给子类处理，将固定的步骤封装在抽象模板中，供子类调用。在本文中，通过签署应用协议的例子详解模板方法模式。

本文示例的完整源代码参见：Github

模板方法模式属于行为型模式，模板方法模式可以定义一系列算法步骤，将不确定的步骤移交给子类完成。本文将以Java为例，带你重温GoF设计模式之模板方法模式，并深入理解模板方法模式及其应用场景。

Java设计模式再相识 (十三)——模板方法模式

在计算机文件系统中，文件夹是一种特殊的文件，它可以放入文件，也可以放入其他文件夹，即子文件夹。在子文件夹中，也可以继续嵌套文件夹，文件夹形成了一种树形的结构。在软件开发中，我们通常使用组合模式来进行这种整体-部分结构的管理。

组合模式 #

组合模式（Composite）：组合模式又被称为整体-部分（Part-Whole）模式，属于结构型模式。它能够将对象组合成为具有树状层次结构，能够使容器（树枝）和内容（叶子）保持一致，便于开发人员进行管理，调用。

组合模式经常用在操作树状数据的场景中。我们称树顶层节点为根节点，根节点下可以包含树枝节点和叶子节点，并且支持循环嵌套，即树枝节点下又可以包含树枝节点和叶子节点。（如：操作系统的文件系统就是一种嵌套递归的树状结构，可以考虑使用组合模式来实现。）

 组合模式的结构 

组合模式由以下结构实现：

- 叶子（Leaf）：表示内容的类，叶子中不能放入其他对象。例如操作系统中的文件不能放入文件夹。
- 树枝（Composite）：组合模式中表示容器的对象，可以在树枝下放入叶子和树枝。例如操作系统中的文件夹，既可以放入文件又可以放入子文件夹。
- 抽象组件（Component）：使容器和内容具有一致性的对象，它为叶子和树枝定义了公共接口。

 实际应用场景 

- 文件系统：无论是在操作系统的文件系统中还是在其他例如网盘等文件系统，都需要大量使用递归嵌套的树状结构。这个时候就特别适合使用组合模式进行文件的管理。
- 决策树的定制：例如推荐系统需要根据人群，性别，年龄，标签多个维度来进行决策推荐，就可以使用组合模式来产生决策树进行精准推荐，而不需要使用大量的if else语句来判断所需要的选择的分支。

 组合模式的两种形式 

组合模式分为以下两种形式：

- 透明组合模式
- 安全组合模式

这两种实现形式的区别仅在于提供操作的方法由哪个类进行管理。树的操作方法通常有add() remove() getChildren()等。在透明组合模式中，直接由组件（Component）进行操作方法的管理。在安全组合模式中，操作方法由树枝（Composite）进行管理。

下文我们将以实际例子讲解为什么需要这两种不同模式以及这两种实现的形式。

 示例 

我们来模拟操作系统的文件系统结构，实现一个最简单的文件系统。这个文件系统能够添加文件夹和文件，并且文件夹中能够包含n个子文件夹。使用组合模式完成。

 透明模式 

首先，我们创建一个抽象组件（Component）：

TreeComponent.java

`java
package com.yeliheng.composite;

import java.util.List;

/
 * 抽象组件：用于保持树枝和叶子的一致性
 */
public interface TreeComponent {

    TreeComponent add(TreeComponent node);

    List<TreeComponent> getChildren();

    void remove(TreeComponent node);

}
`
这个抽象组件中，我们提供了三个方法，分别是add()添加，getChildren()获取所有子节点，remove()删除方法。待会创建的文件夹和文件都将实现抽象组件中提供的方法。这里，你可能会注意到一个问题。如果在文件中继续添加文件夹或者文件，那会出现什么情况？没错，这就是透明模式的瓶颈所在。透明模式直接将方法定义在了抽象组件中，导致实现它的所有对象都必须实现其提供的方法。在我们定义的规则下，不允许文件中存在子文件夹或者文件，所以实现方法时就必须抛出异常。

接下来，我们创建文件夹对象。文件夹对象属于我们的树枝节点。它下面可以有无数个子节点。

Directory.java

`java
package com.yeliheng.composite;

import java.util.ArrayList;
import java.util.List;

/
 * 树枝节点：文件夹
 */
public class Directory implements TreeComponent{
    //文件夹名
    private String name;
    //列表
    private List<TreeComponent> list = new ArrayList<>();

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

    @Override
    public TreeComponent add(TreeComponent node) {
        list.add(node);
        return this;
    }

    @Override
    public List<TreeComponent> getChildren() {
        return list;
    }

    @Override
    public void remove(TreeComponent node) {
        list.remove(node);
    }
}
`

我们使用List来管理我们的树形数据。

接着进行文件的实现

File.java

`java

package com.yeliheng.composite;

import java.util.List;

/
 * 叶子节点：文件
 */
public class File implements TreeComponent{

    //文件名
    private String filename;

    public File(String filename) {
        this.filename = filename;
    }

    @Override
    public TreeComponent add(TreeComponent node) {
        //文件下不能新建文件或文件夹
        throw new UnsupportedOperationException();
    }

    @Override
    public List<TreeComponent> getChildren() {
        return null;
    }

    @Override
    public void remove(TreeComponent node) {
        //文件下没有东西可供删除
        throw new UnsupportedOperationException();
    }
}

`

在文件对象中，若试图调用add()方法或remove()方法将造成异常的抛出。

最后，我们在main函数中构建这棵文件树，并使用IDEA的Debug工具来查看我们构建好的树形结构。

Main.java

`java

package com.yeliheng.composite;

public class Main {

    public static void main(String[] args) {
        TreeComponent rootElement = new Directory("文件夹1");

        rootElement.add(new Directory("子文件夹1")
                .add(new File("文件1"))
                .add(new File("文件2"))
        );

        rootElement.add(new Directory("子文件夹2"));

        System.out.println(rootElement);
    }
}

`

创建好树形数据后，我们将断点设置在System.out.println(rootElement)处，查看rootElement变量的值。

!output.png

可以看到，这棵树构建正确。

当我们试图对文件对象进行add操作时，异常抛出。如下图所示：

!output.png

接下来，我们使用安全模式对程序进行修改。

 安全模式 

实现安全组合模式只需要将定义在Component对象中的方法移动到树枝节点中即可防止子节点的错误调用。

在本例中，我们移动TreeComponent类中的add()方法和remove()方法到Directory中，这样就能防止File对add()和remove()进行调用。

详细代码如下：

TreeComponent.java

`java

package com.yeliheng.composite;

import java.util.List;

/
 * 抽象组件：用于保持树枝和叶子的一致性
 */
public interface TreeComponent {

    List<TreeComponent> getChildren();

}

`
Directory.java

`java
package com.yeliheng.composite;

import java.util.ArrayList;
import java.util.List;

/
 * 树枝节点：文件夹
 */
public class Directory implements TreeComponent{
    //文件夹名
    private String name;
    //列表
    private List<TreeComponent> list = new ArrayList<>();

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

    public TreeComponent add(TreeComponent node) {
        list.add(node);
        return this;
    }

    @Override
    public List<TreeComponent> getChildren() {
        return list;
    }

    public void remove(TreeComponent node) {
        list.remove(node);
    }
}

`

File.java

`java
package com.yeliheng.composite;

import java.util.List;

/
 * 叶子节点：文件
 */
public class File implements TreeComponent{

    //文件名
    private String filename;

    public File(String filename) {
        this.filename = filename;
    }

    @Override
    public List<TreeComponent> getChildren() {
        return null;
    }

}

`

这样就实现了安全组合模式。

 组合模式的优缺点 

 优点 

- 使用组合模式能够使调用者一致地处理容器和对象，无需关心“树枝节点”和“叶子节点”的区别。
- 满足开闭原则，可以在不修改源代码的情况下进行新对象的操作。

 缺点 

- 过度使用会增加软件的层级关系，提高系统复杂度。

总结 #

本文以操作系统的文件系统为例，讲解了组合模式的两种实现形式：透明组合模式、安全组合模式。

本文示例的完整源代码参见：Github

组合模式又被称为整体-部分（Part-Whole）模式，属于结构型模式。本文将以Java为例，带你重温GoF设计模式之组合模式，并深入理解组合模式及其应用场景。

Java设计模式再相识 (十二)——组合模式

在设计项目的过程中，我们经常会遇到创建大量相同或相似对象实例的问题。大量创建对象会造成系统资源的浪费，最终造成系统运行效率低下。如果能将对象中相同的部分提取出来并共享，将大大减小系统资源。我们可以使用享元模式来解决这个问题。

享元模式 #
享元模式（Flyweight）：享元即Flyweight。Flyweight是轻量级的意思。享元模式指当需要某个实例时，不总通过系统关键字new进行实例化，而是尽量使用已经存在的实例，实现实例的共享。享元模式主要共享通用对象，这个通用对象通常是不可改变的或对内存资源占用较高以及需要大量使用数据库资源的对象，因此可进行统一抽离封装作为共享对象使用。

 享元模式的结构 

- 抽象享元（Flyweight）：抽象享元是所有具体享元的父类，为具体享元提供公共接口。
- 具体享元（ConcreteFlyweight）：实现抽象享元类中的接口。
- 享元工厂（FlyweightFactory）：负责创建和管理享元，在工厂中生成的享元可以实现实例的共享。

> 注：在GoF的书中，还有UnsharedConcreteFlyweight角色，即表示非享元对象。非享元即那些不需要进行缓存的对象，在本例中没有出现。

 享元模式的实际应用场景 

- Java中的包装类型（例如：Integer、Byte等）：在Java标准库中，包装类型例如Integer和Byte都是不变类，无需反复创建。所以在多次调用如Integer.valueOf()这样的静态工厂方法时，会自动使用Integer共享的实例。
- 项目中需要高并发、大量数据库操作的地方：例如秒杀场景，一个商品秒杀时往往会存在大量并发。在这样的情况下，如果反复创建数据库连接和数据库行级锁会耗费大量系统资源。这时应该使用缓存，通常会使用redis的分布式锁来控制，使用享元模式将不变的信息进行缓存，节省系统资源。

 示例 

在前后端分离的用户登录中，我们通常会缓存用户信息，以便于前端请求时直接从缓存读取并返回。本例我们来使用过享元模式实现一个对用户信息的缓存。

> 在实际项目中，我们会将信息存储在Redis中，再进行读取返回。本例为了演示方便，具体Redis的逻辑没有体现，仅讲解原理，大家可自行扩展。

首先我们定义一个用户的享元类，即实体类。因为这里用户信息不会经常变动，我们将其进行缓存。

User.java

`java
package com.yeliheng.flyweight;

/
 * 用户享元
 */
public class User {

    //用户Id
    private Long userId;
    //用户名
    private String username;
    //密码
    private String password;
    //昵称
    private String nickname;
    //手机号
    private String phone;
    //电子邮箱
    private String email;

    public Long getUserId() {
        return userId;
    }

    public void setUserId(Long userId) {
        this.userId = userId;
    }

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }

    public String getPassword() {
        return password;
    }

    public void setPassword(String password) {
        this.password = password;
    }

    public String getNickname() {
        return nickname;
    }

    public void setNickname(String nickname) {
        this.nickname = nickname;
    }

    public String getPhone() {
        return phone;
    }

    public void setPhone(String phone) {
        this.phone = phone;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }
}
`
用户享元中包含用户id、用户名、密码、昵称、手机号、电子邮箱信息。

> 注1：因为本例只存在一个享元类，故没有使用到抽象享元的角色。

接着，我们创建一个享元工厂。这里采用静态工厂模式实现。

UserFlyweightFactory.java

`java
package com.yeliheng.flyweight;

import java.util.HashMap;
import java.util.Map;

/
 * 用户享元工厂
 */
public class UserFlyweightFactory {
    private static final Map<String, User> cache = new HashMap<>();

    public static void getUser(long userId) {
        String key = String.valueOf(userId);
        User user = cache.get(key);
        if(user == null) {
            System.out.println("找不到缓存的用户数据，自动生成用户信息！");
            user = new User();
            user.setUserId(userId);
            user.setUsername("yeliheng");
            user.setPassword("12356");
            user.setNickname("Yeliheng");
            user.setEmail("yeliheng00@163.com");
            cache.put(key,user);
        } else {
            System.out.println("缓存中存在用户数据：" + "用户名 " + user.getUsername());
        }
    }
}
`

在用户享元工厂中，我们使用一个Map对象来模拟用户信息在Redis中的存取。

我们定义一个静态方法getUser()，getUser()方法接收一个userId来获取缓存的对象。接着我们进行判断，如果缓存中存在用户数据，则直接使用缓存的数据。否则，系统将创建一个用户对象，并写入到缓存中。实际项目中，用户的信息从前端传递过来的Body体中进行获取。

最后，我们来调用两次静态工厂获取用户信息，看看效果。

Main.java

`java

package com.yeliheng.flyweight;

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

        UserFlyweightFactory.getUser(1L); //第一次调用

        UserFlyweightFactory.getUser(1L); //第二次调用
    }
}

`
最终运行结果如下：

!output.png

可以看到，第一次调用，缓存中并没有我们想要的信息，系统自动创建了对象，并将对象写入缓存，供第二次调用使用。

 享元模式的优缺点 

 优点 

- 缓存可以重复使用的对象，节省系统的内存开销。

 缺点 

- 为了共享对象，需要将某些对象导出到外部，即让外部能够调用。过度使用可能会适得其反，导致开销增加。

总结 #

当一个对象不会变化或不需要经常变化，就可以考虑享元模式来缓存对象，节省系统资源。

本文通过举例用户数据缓存来详细讲解了享元模式的应用场景。

本文示例的完整代码参见: Github

享元模式属于结构型模式，使用享元模式可共享通用对象，减少内存占用。本文将以Java为例，带你重温GoF设计模式之享元模式，并深入理解享元模式及其应用场景。

Java设计模式再相识 (十一)——享元模式(Flyweight)

在软件开发中，往往需要同多个子系统打交道。使用者往往需要了解各个子系统的接口，这会造成开发成本的提升。如果我们将系统看作一个黑盒，黑盒负责与子系统进行通讯，那么使用者就无需了解系统内部实现即可使用这个系统。外观模式就相当于一个黑盒子，将系统内的接口“保护”起来，并供给用户使用。

外观模式 #

外观模式（Facade）：外观模式也叫门面模式，可为复杂的子系统提供一个调用的接口封装子系统使得这些子系统更便于开发人员的使用。外部应用程序无需关心子系统的具体实现，可以大大降低系统复杂度，提升程序的可拓展性。外观模式是迪米特法则的典型应用。

> 迪米特法则：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

在项目的开发中，外观模式是我们使用广泛的一种模式。你肯定有过将一系列接口封装成一个工具类以供外部调用的经历。这就是外观模式的简单体现。在开源库、开源框架以及第三方SDK中，外观模式就被广泛应用。

 外观模式的结构 

- 外观（Facade）：封装多个子系统，对外提供一个可供调用的外部接口。
- 子系统（SubSystem）：即系统的各个组成部分，使用者可通过外观提供的接口访问子系统。 

 实际应用场景 

- 工具类：例如密码工具类等
- 中间件的封装
- 开源类库

 示例 

在项目中，我们通常需要对用户上传的图像进行压缩处理。我们可能需要将复杂的图像压缩算法进行封装，并使用一个统一的接口便于开发人员日后的调用和维护。这里我们使用外观模式来实现。

首先，我们创建用于图像压缩的逻辑（即子系统），这里具体压缩过程不予展示，仅展示设计模式的基本结构。

ImageReader.java

`java
package com.yeliheng.facade;

/
 * 子系统-图像读取器
 */
public class ImageReader {
    public ImageReader() {
        //TODO：图像读取逻辑...
        System.out.println("读取图像！");
    }
}
`

这个子系统类用于图形的读取。

ImageCompression.java

`java
package com.yeliheng.facade;

/
 * 子系统-图像压缩器
 */
public class ImageCompression {
    public void png(ImageReader reader) {
        //TODO: 图像压缩逻辑...
        System.out.println("图像已被压缩，输出格式: png");
    }

    public void jpg(ImageReader reader) {
        //TODO: 图像压缩逻辑...
        System.out.println("图像已被压缩，输出格式: jpg");
    }
}

`
在子系统ImageCompression中，我们提供了两种压缩格式：png和jpg。

接着我们创建外观类。

CompressFacade.java

`java
package com.yeliheng.facade;

/
 * 外观
 */
public class CompressFacade {

    private ImageReader imageReader = new ImageReader();

    private ImageCompression compression = new ImageCompression();

    public void compress() {
        compression.jpg(imageReader);
    }
}
`

可以看到在外观类中，我们将调用图像压缩的方法进行了封装，在compress()方法中统一调用。这样，开发者在使用的时候，无需关心压缩算法的实现，可以直接调用外观类中的压缩方法就可以完成图像的压缩。大大减小工程复杂性，提高开发效率。

最后我们就可以使用写好的外观模式了。

Main.java

`java
package com.yeliheng.facade;

public class Main {
    public static void main(String[] args) {
        System.out.println("开始进行图像压缩");
        CompressFacade compressFacade = new CompressFacade();
        compressFacade.compress();
    }
}
`

我们实例化一个CompressFacade类，对类中的compress进行调用即可。

最终输出结果如下：

!output.png

 外观模式的优缺点 

 优点 

- 降低了子系统与调用者间的耦合度，使得系统成为一个黑盒。
- 降低了开发人员阅读源码的成本，提升项目的可维护性。

 缺点 

- 增加子系统可能需要修改外观类和调用者的代码，这违反了“开闭原则”。
- 过度使用会造成系统类过多接口的暴露，可能造成无法预料的问题。

总结 #

外观模式是一种很日常的设计模式，它常常无意间出现在我们的开发中。我们可以通过这种设计模式减小调用者使用系统的难度，将复杂的子系统进行封装，提升系统的可维护性和拓展性。

本文示例的完整源代码参见：Github

外观模式属于结构型模式。本文将以Java为例，带你重温GoF设计模式之外观模式，并深入理解外观模式及其应用场景。

Java设计模式再相识 (十)——外观模式

在项目的开发中，经常需要复用一些现成的组件，但是又想在现成组件的基础上拓展一些功能，并且不希望改变组件结构。这就很适合使用装饰器模式来实现。装饰器模式，顾名思义就是对一个对象进行“装饰”。举个生活中的例子，一个白色的蛋糕可以在上面淋上巧克力酱，放上草莓，放上各种小摆件，做成不同样式的生日蛋糕。软件开发也是如此，有时，我们的对象也需要进行“装饰”。这种不改变原有类实现拓展的方式，你可能会想到继承或者动态代理和AOP面向切面编程。很不错，这些方法也能实现以上需求，但是有些情况下，使用装饰器会更加灵活，可以避免继承带来的子类过多的问题或者动态代理和面向切面编程带来复杂度增加的问题。

装饰器模式 #

 定义 

装饰器模式（Decorator）：在不改变现有对象结构的情况下，动态地赋予对象额外的功能。

 装饰器模式的结构 

装饰器模式的结构如下：

- 抽象组件（Component）：即增加功能时的核心类，它定义了“装饰”所必须的抽象接口。
- 具体组件（ConcreteComponent）：具体组件实现了抽象组件中定义的接口。
- 抽象装饰（Decorator）：继承抽象组件，并包含具体组件的实例，可以通过其子类扩展具体组件的功能。Decorator类知道自己要装饰的对象。
- 具体装饰（ConcreteDecorator）：实现抽象装饰的方法，并给具体组件（ConcreteComponent）添加新功能。

 实际应用场景 

- Java中的文件流：在读取文件时，我们经常会使用new BufferedReader(new FileReader(""));进行嵌套实例化，这种嵌套调用转型的方式就是一种装饰器模式的体现。如果没有使用这种方式，子类的数目将大幅增长，难以维护。

- 双重认证：在账号密码输入完成之后，往往需要进行手机短信验证码的双重认证。这个时候就可以考虑使用装饰器模式，在原来逻辑不变的情况下可以扩展登录模块。

 示例 

有些时候，我们点击登录按钮，会跳出移动滑块直至图形拼合的验证码，在通过了人机验证后，又会出现手机短信验证的需求。这个时候，我们就可以采用装饰器模式进行嵌套验证。不用修改登录逻辑。

接下来，我们开始使用装饰器模式实现这个需求。

首先，我们来实现抽象组件。

ILoginComponent.java

`java
package com.yeliheng.decorator;

/
 * 抽象组件
 */
public interface ILoginComponent {
    void login();
}
`
我们在抽象组件中定义了一个登录接口。

接着我们来实现这个接口。

LoginComponentImpl.java

`java
package com.yeliheng.decorator;

/
 * 具体组件
 */
public class LoginComponentImpl implements ILoginComponent{
    @Override
    public void login() {
        System.out.println("登录成功！");
    }
}
`

可以看到，具体组件实现了抽象组件的接口方法。我们为了演示清晰，直接输出登录成功。

这个时候，我们需要为登录接口加上图形验证码和短信验证码。并且在图形验证码通过后才可以使用短信验证码。

装饰器登场了。我们创建一个抽象装饰器。

AbstractDecorator.java
`java
package com.yeliheng.decorator;

/
 * 抽象装饰
 */
public class AbstractDecorator implements ILoginComponent{
    protected ILoginComponent component;

    public AbstractDecorator(ILoginComponent component) {
        this.component = component;
    }

    @Override
    public void login() {
        component.login();
    }
}
`
抽象装饰器中，实现了抽象组件。并且包含一个抽象组件实例的引用，以构造函数的方式注入。重写了抽象组件中的login()方法。这样做的目的是将引用建立到后面传入的对象中，以便使用对象中的处理逻辑。

现在我们可以开始写具体的装饰器了。

图像验证码装饰器：
ImageCaptcha.java

`java
package com.yeliheng.decorator;

/
 * 图形验证码-具体装饰
 */
public class ImageCaptcha extends AbstractDecorator{
    public ImageCaptcha(ILoginComponent component) {
        super(component);
    }

    @Override
    public void login() {
        System.out.println("图形验证已通过！");
        super.login();
    }
}
`

短信验证码装饰器：
SmsCaptcha.java
`java
package com.yeliheng.decorator;

/
 * 具体装饰-短信验证码
 */
public class SmsCaptcha extends AbstractDecorator{
    public SmsCaptcha(ILoginComponent component) {
        super(component);
    }

    @Override
    public void login() {
        System.out.println("短信验证码验证通过!");
        super.login();
    }
}
`
可以看到装饰器继承了抽象装饰器，并且在构造函数中，传入抽象组件的引用，并传给父类，实现嵌套。

最后我们来使用写好的装饰器。

Main.java

`java

package com.yeliheng.decorator;

public class Main {
    public static void main(String[] args) {
        ImageCaptcha imageCaptcha = new ImageCaptcha(new SmsCaptcha(new LoginComponentImpl()));
        imageCaptcha.login();
    }
}

`
在Main函数中，我们嵌套调用，谁要在最前面执行，就把它放到最外层。我们实例化一个图形验证码的装饰器，并且在其中传入短信验证码装饰器，最后将登录组件的具体实现传入到短信验证码的装饰器中。通过一系列巧妙的嵌套调用，我们成功在不修改原有逻辑的情况下引入了两种认证方式便于后期的拓展。

最终代码的执行效果如下：

!zsq

依次通过了图形验证、短信验证，最后登录成功。

 装饰器模式的优缺点 

 优点 

- 装饰器是继承的有力补充，基于继承进行升级，更加灵活。
- 能够在不改变原来对象逻辑的情况下动态进行功能拓展。
- 完全遵循开闭原则。

 缺点 

- 过度使用装饰器会增加子类，增加程序复杂度。

 总结 

本文通过对登录接口的嵌套封装改造详细讲解了装饰器模式，完全基于软件开发中的实际场景进行讲解，有助于融会贯通。

示例的完整代码参见：Github

装饰器模式属于结构型模式，可以在结构不变的情况下动态拓展组件的功能。本文将以Java为例，带你重温GoF设计模式之装饰器模式，并深入理解装饰器模式及其应用场景。

Java设计模式再相识 (九)——装饰器模式

要想将两个目的地进行连接，你需要一座桥梁。在软件开发中，我们可能会遇到需要将两种维度的对象进行整合，让其能够运行在一个系统中。例如输出不同颜色和字体的日志，如果使用传统的继承方式，我们要写很多的子类才能实现。通过桥接模式，我们就可以很好地解决这个问题。

桥接模式 # 

桥接模式：即Bridge，它可以将抽象与实现分离，让这些组合可以自由地独立变化，从而降低抽象和实现之间的耦合度。桥接模式适用于类的层级结构复杂的场景中，常与适配器进行组合使用，在两个不同对象之间添加适配器以进行不同对象的正确桥接。光看概念可能有些抽象，下文我们将会通过具体示例进行讲解。

桥接模式的结构 #

- 抽象化（Abstraction）：抽象类的定义，它将使用“实现者（Implementor）”中的方法定义基本的功能。抽象化类中保存了一个实现者（Implementor）的实例。
- 扩展抽象化（RefinedAbstraction）：在抽象化类的基础上增加了新的功能，它是抽象化角色的子类，并实现父类中的业务方法。
- 实现者（Implementor）：实现者定义了用于实现Abstraction的接口方法，以供扩展抽象化类进行调用。
- 具体实现者（ConcreteImplementor）：该类负责实现Implementor中定义的接口。

实际应用场景 #

- JDBC驱动：JDBC中巧妙使用了桥接模式来进行多种数据库的适配。在修改数据库时，用户只需要简单地修改配置文件，然后就可以使用与原来数据库相同的API，无需伤筋动骨地对整个项目进行修改适配。
- 指纹/人脸支付场景：在我们使用微信，支付宝进行支付时，会有多种鉴权方法，例如支付密码，指纹，人脸支付。这时就适合使用桥接模式进行逻辑的编写。

示例 #

本文将以支付场景，详解桥接模式的应用。

我们购买商品的最后一步就是支付。电商平台通常会让你选择支付方式，这里以微信和支付宝为例。

假设某电商平台的支付方式为微信，支付宝支付。鉴权方式有支付密码，指纹，人脸支付，让用户自行选择。

如果我们使用传统方式进行开发，我们会想到这几种组合：微信->密码，微信->人脸，支付宝->密码......

这会导致我们使用大量的if else语句来判断用户的行为，代码将杂乱无章。本例我们来使用桥接模式解决这个需求。

首先我们创建支付的抽象鉴权类，也就是结构中的实现者。

IPaymentAuthorization.java

`java
package com.yeliheng.bridge;

/
 * 鉴权方式
 */
public interface IPaymentAuthorization {
    boolean authorization();
}
`
实现者中提供了一个鉴权接口authorization()，方便后面三种鉴权模式的接入。

接着，定义一个抽象化类

PayAbstraction.java

`java
package com.yeliheng.bridge;

/
 * 抽象化类
 */
public abstract class PayAbstraction {

    protected IPaymentAuthorization paymentAuth;

    public PayAbstraction(IPaymentAuthorization paymentAuth) {
        this.paymentAuth = paymentAuth;
    }

    /
     * 支付
     * @param payer 转账者
     * @param payee 收款者
     */
    public abstract void pay(String payer,String payee,Long amount);

}
`
抽象化类中使用构造函数的方式注入IPaymentAuthorization接口，并定义了一个抽象方法pay()，用于处理转账逻辑。

接着我们分别创建微信和支付宝两个平台的支付类，实现抽象化类中的抽象方法。

WechatPay.java

`java
package com.yeliheng.bridge;

/
 * 扩展抽象化
 */
public class WechatPay extends PayAbstraction{

    public WechatPay(IPaymentAuthorization paymentAuth) {
        super(paymentAuth);
    }

    /
     * 支付
     *
     * @param payer 转账者
     * @param payee 收款者
     */
    @Override
    public void pay(String payer, String payee, Long amount) {
        System.out.println("[订单创建] 转账人: " + payer + " 收款者: " + payee + " 转账金额: " + amount);
        System.out.println("[系统] 开始校验身份...");
        boolean auth = paymentAuth.authorization();
        if(auth) {
            System.out.println("[信息] 微信支付成功！转账人: " + payer + " 收款者: " + payee + " 转账金额: " + amount);
        }
    }
}

`

Alipay.java

`java
package com.yeliheng.bridge;

/
 * 扩展抽象化
 */
public class Alipay extends PayAbstraction{

    public Alipay(IPaymentAuthorization paymentAuth) {
        super(paymentAuth);
    }

    /
     * 支付
     *
     * @param payer 转账者
     * @param payee 收款者
     */
    @Override
    public void pay(String payer, String payee, Long amount) {
        System.out.println("[订单创建] 转账人: " + payer + " 收款者: " + payee + " 转账金额: " + amount);
        System.out.println("[系统] 开始校验身份...");
        boolean auth = paymentAuth.authorization();
        if(auth) {
            System.out.println("[信息] 支付宝支付成功！转账人: " + payer + " 收款者: " + payee + " 转账金额: " + amount);
        }
    }
}
`
最后，我们需要创建三种鉴权方式的类，来对实现者进行实现。

密码验证：PasswordAuthorization.java

`java
package com.yeliheng.bridge;

public class PasswordAuthorization implements IPaymentAuthorization{

    @Override
    public boolean authorization() {
        //TODO: 具体的密码验证逻辑...
        System.out.println("[系统] 支付密码验证通过!");
        return true;
    }
}
`

指纹验证：FingerprintAuthorization.java

`java
package com.yeliheng.bridge;

public class FingerprintAuthorization implements IPaymentAuthorization{
    @Override
    public boolean authorization() {
        //TODO: 具体的指纹验证逻辑...
        System.out.println("[系统] 指纹验证通过!");
        return true;
    }
}
`

人脸验证：FaceAuthorization.java

`java
package com.yeliheng.bridge;

public class FaceAuthorization implements IPaymentAuthorization{
    @Override
    public boolean authorization() {
        //TODO: 具体的人脸验证逻辑...
        System.out.println("[系统] 人脸验证通过!");
        return true;
    }
}
`
为了演示效果，我们直接默认验证通过，并返回true。

处理完这些逻辑后，我们可以开始使用桥接模式实现的支付了。

Main.java

`java
package com.yeliheng.bridge;

public class Main {
    public static void main(String[] args) {
        //微信人脸支付
        System.out.println("用户选择使用微信人脸支付，开始模拟。");
        PayAbstraction wechatPay = new WechatPay(new FaceAuthorization());
        wechatPay.pay("Yeliheng","Gnehiley",100000L);

        //支付宝指纹支付
        System.out.println("\n用户选择使用支付宝指纹支付，开始模拟。");
        PayAbstraction alipay = new Alipay(new FingerprintAuthorization());
        alipay.pay("Yeliheng","Gnehiley",100000L);
    }
}
`

在main函数中，我们定义了抽象者实例，并将其实例化为具体的支付平台：微信支付和支付宝支付。然后在平台的构造函数中调用所需的鉴权处理类。最后调用pay()方法进行支付。这就使用了桥接模式将平台与支付鉴权模式进行桥接，大大减小了代码耦合度。

最终运行结果如下：

!output.png

 桥接模式的优缺点 

 优点 
- 满足单依职责和开闭原则。
- 提高项目的可拓展性，给后续需求预留了扩展空间。

 缺点 

- 过度使用可能造成代码复杂度提升，增加开发的难度。

总结 #

本例以微信和支付宝支付为例，详细讲解了桥接模式在微信支付宝中不同支付方法的应用。

本文示例的完整源代码参见：Github

桥接模式属于结构型模式，它可以用于在类的两个层次结构之间搭建桥梁。本文将以Java为例，带你重温GoF设计模式之桥接模式，并深入理解桥接模式及其应用场景。

标签：Java