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

模板方法模式 #

模板方法模式（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设计模式再相识 (八)——桥接模式

如果你想让额定工作电压12V的笔记本电脑在220V的家用交流电下工作，你会怎么做？通常，你不需要自己进行转换。买电脑时会配套一个电源适配器（AC Adapter），这个适配器的作用就是将220V的家庭电压转换为我们所需要的12V笔记本的电压。这样做笔记本才不会被烧坏。
在软件开发中，也经常会存在现有的程序无法直接进行使用，需要进行一些转换才能正常使用。这就引入了适配器（Adapter）模式。

适配器模式 #

适配器(Adapter)模式：Adapter模式也被称为Wrapper模式。Wrapper有包装、封装的意思。顾名思义，适配器模式通过一系列操作将我们要转换的对象进行封装，使其能够拥有其它用途。

适配器模式分为以下两种形式：

- 类适配器模式
- 对象适配器模式

下文我们将详细讲解这两种模式。

 适配器模式的结构 

适配器模式包含以下结构：

1. 目标对象（Target）：即业务所需要转换的最终形态。例如上文笔记本电脑需要的12V电源。
2. 被适配者（Adaptee）：被适配者对象是一个包含既定方法的对象。例如上文中的220V家庭用电。
3. 适配器（Adapter）：适配器模式的核心对象。它是一个转换器，能够通过继承或委托来把被适配者转换为目标对象。

 实际应用场景 
- 第三方登录
- 多数据源项目的适配 

接下来我们来讲解类适配器模式。

 类适配器模式 

类适配器模式即使用继承的适配器模式。类适配器模式类之间的耦合度较高，这会导致框架的开发者需要了解现有框架中的相关实现类的内部结构，所以应用也较少。用得较多的是对象适配器模式（下文介绍）。

 示例 

本文，我们将使用适配器模式实现一个第三方登录的适配器。我们先使用类适配器来实现。

现在，我们的项目有一个需求，需要在原来账号密码登录的基础上，接入QQ和微信两种第三方登录方式。

我们先来使用类适配器实现。

首先，新建一个目标接口，这个接口中定义了我们需要的登录方法。

Target.java

`java
package com.yeliheng.adapter.classadapter;

/
 * 被适配的目标
 */
public interface Target {

    public void login();

}
`

我们定义了一个login()方法，这也是适配的最终对象。

接着，我们定义一个Adaptee，即将被适配的对象。

Adaptee.java

`java
package com.yeliheng.adapter.classadapter;

/
 * 被适配者
 */
public class Adaptee {
    public void wechatLogin() {
        System.out.println("微信登录成功，Token为xxx");
    }

    public void qqLogin() {
        System.out.println("qq登录成功，Token为xxx");
    }
}
`

因为我们最终需求需要适配成微信和QQ两种登录方式，所以被适配的对象是微信登录和QQ登录。我们在登录后返回token，这里简单地输出模拟这种场景。

然后我们就可以开始写适配器了。

LoginAdapter.java

`java
package com.yeliheng.adapter.classadapter;

/
 * 适配器
 */
public class LoginAdapter extends Adaptee implements Target{
    @Override
    public void login() {
        wechatLogin(); // 微信登录
    }
}
`
在登录适配器中，我们继承了Adaptee，即被适配者，也就是类适配器模式的写法，然后我们实现了Target目标类中的login()方法，实现了微信登录。

调用登录：

Main.java

`java
package com.yeliheng.adapter.classadapter;

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

        System.out.println("适配器测试：尝试微信登录...");

        Target target = new LoginAdapter();
        target.login();
    }
}
`
main函数中，我们实例化了一个LoginAdapter并赋值给Target目标类型。因为在适配器中，我们已经将不能直接使用的对象转换成我们可以使用的对象了。然后我们直接调用target中的login方法，即可实现第三方登录。具体业务场景中，我们需要判断用户行为选择登录的平台。

本例输出结果如下：

!output.png

 对象适配器模式 

接下来，我们来继续讲解对象适配器模式。对象适配器模式是一种使用委托（delegate）的适配器模式。即：将某个方法中的实际处理逻辑移交给其他实例的方法进行处理。

 示例 

我们继续以第三方登录为例，实现对象适配器。

对象适配器的实现方式除了Adapter类，其他类均与类适配器相同。这里仅给出不同的类的源码。完整源代码参见Github

LoginObjectAdapter.java

`java
package com.yeliheng.adapter.objectadapter;

public class LoginObjectAdapter implements Target{

    private Adaptee adaptee;

    public LoginObjectAdapter(Adaptee adaptee) {
        this.adaptee = adaptee;
    }

    @Override
    public void login() {
        adaptee.qqLogin();
    }
}

`

Main.java

`java
package com.yeliheng.adapter.objectadapter;

public class Main {
    public static void main(String[] args) {
        System.out.println("适配器测试：尝试登录...");

        Adaptee adaptee = new Adaptee();
        Target target = new LoginObjectAdapter(adaptee);
        target.login();
    }
}

`

通过代码我们可以看出与类适配器模式不同的是，对象适配器不直接使用继承的方式实现适配，而是以构造函数注入的方式。这样做的好处在于：Java是单继承语言，若直接使用类适配器的继承，那么只能继承一种被适配者。如果我们需要灵活引入适配者，这样的方式就无法满足我们的需求。于是我们采用对象适配器，通过构造函数传入被适配者的对象，从而达到适配多种适配者的目的。

代码的输出结果如下：

!output.png

 适配器模式的优缺点 

 优点 
- 能够使现有的类得到复用：程序员无需修改代码即可使用现有的适配者类。
- 降低项目耦合度：能够有效解决目标接口与现有接口的区别。
- 版本升级的兼容性：软件升级往往不能对已经暴露的API进行修改，这时就可以使用适配器进行向下兼容，达到高版本兼容低版本的目的。

 缺点 
- 过度使用适配器会增加系统的复杂性，降低代码的可读性。

总结 #
本文详细讲解了适配器模式的两种实现方式，分别是类适配器模式和对象适配器模式。并使用第三方登录作为例子实现了适配器。

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

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

Java设计模式再相识 (七)——适配器模式

项目开发中，我们有时通常不能直接访问一个对象，需要一个中间层来代理完成。例如租房往往不会直接联系房东，而是通过中介。中介就是充当代理的角色，直接跟用户交谈。这是生活中的例子。在软件开发中，代理模式也被广泛使用。本文将详细介绍代理模式的实现以及应用场景。

代理模式 #

代理模式（Proxy)：当一个对象被禁止直接使用另外一个对象时，往往需要使用一个代理对象以实现对该对象的间接使用，代理对象作为访问对象和目标对象之间的中介，这就是代理模式。在软件开发中，代理模式可以用于隐藏复杂任务，例如网络通信之间的复杂协议就可以使用代理进行封装。代理模式也可以用于某些对安全性要求较高的场景。例如一个不希望用户关心内部细节的防火墙系统。代理模式分为静态代理和动态代理，下文我们将详细介绍这两种代理方式。其实在实际项目的开发中，直接使用静态代理的场景并不多见，但掌握代理模式，可以让你能够轻松看懂一些模块的源码。

我们从静态代理开始介绍。

 静态代理(基础) 

静态代理，即开发者手动编写的代理。开发者自己编写代理类，并编译成.class文件。在程序执行前，这些文件就已经被写好并编译完成了。这样的代理称为静态代理。

 静态代理的应用场景 

- 文件上传：通过静态代理实现大文件的上传以及访问。
- 隐藏接口：有些接口不希望直接暴露到外部容器，需要使用静态代理实现中间件来隐藏接口。

 代理模式的结构 

1. 抽象主题（Subject）：通过接口或抽象类提供抽象的业务方法。
2. 真实主题（Real Subject）：实现抽象主题的具体方法，是代理类最终调用的对象。
3. 代理（Proxy）：也叫做委托类，它负责对真实角色进行调用，把所有抽象主题定义的方法委托给真实主题来实现，并且在真实主题处理代码逻辑前后做相关的预处理或后处理。

 静态代理示例 

在本节的示例中，我们来模拟使用代理模式实现一个发送短信验证码接口的程序。

首先我们实现抽象主题：

ISmsService.java

`java
package com.yeliheng.proxy;

/
 * 抽象主题
 */
public interface ISmsService {

    void send(String message); // 发送短信验证码

}
`
抽象主题中提供了send()方法来发送验证码。

接着，我们实现真实主题。

SmsService.java

`java
package com.yeliheng.proxy;

/
 * 真实主题
 */
public class SmsService implements ISmsService{

    @Override
    public void send(String message) {
        System.out.println("发送短信成功，内容为：" + message);
    }
}
`
真实主题中实现了send()方法，输出我们需要的内容。

最后来实现代理类。

SmsProxy.java

`java

package com.yeliheng.proxy;

/
 * 代理类
 */
public class SmsProxy implements ISmsService{
    private final SmsService smsService;

    public SmsProxy(SmsService smsService) {
        this.smsService = smsService;
    }

    @Override
    public void send(String message) {
        //在这里执行相关的预处理操作...
        //-------------

        //发送验证码
        smsService.send(message);

        //后处理操作...
        //--------------
    }
}
`
我们可以注意到，代理类实现了ISmsService抽象主题而并非直接实现真实主题。然后我们通过构造函数进行注入，获取到真实主题的实例。并重写抽象主题中的send()方法，在send()方法中调用具体主题的send()方法。这样我们就实现了一个代理。使用者不用直接访问具体的主题，而是通过代理来进行访问操作。这样做，我们就可以隐藏真实主题的具体逻辑，并且在代理中可以实现相关的预处理（例如发送前先弹出图形验证码，图形验证码正确才发送短信验证码）和后处理（成功发送后，记录发送日志和手机号信息，防止接口滥用）操作，而无需去修改真实主题的代码，这样可以提升系统的可拓展性。

我们在main函数中进行模拟调用：

Main.java

`java
package com.yeliheng.proxy;

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

        //生成验证码
        int code = 123456;
        //使用代理发送短信验证码
        SmsService smsService = new SmsService();
        SmsProxy proxy = new SmsProxy(smsService);
        proxy.send("您的短信验证码是" + code);
    }
}

`

最后可以看到本例的输出结果：

!output.png

这样我们就实现了一个简单的静态代理。

接下来，我们来讲讲静态代理的优缺点。

 静态代理的优缺点 

 优点 

- 能够隐藏实例的真实调用。
- 可拓展性高，在需要加入预处理和后处理代码时，无需修改真实主题的具体代码。

 缺点 

- 代理类和委托类（抽象主题）实现了相同的接口，代理类通过委托类实现了相同的方法。这样就出现了大量的代码重复。
- 代理对象只服务于一种类型的对象，如果要服务多类型的对象，需要编写多个代理类。（这个问题可通过动态代理进行解决）

 动态代理(进阶) 

讲完了静态代理，我们来看看什么是动态代理。

动态代理：静态代理中的每个代理类只能为一个接口服务，这样，在复杂项目中必然会产生许多的代理类，又会有许多重复的代码。与静态代理不同，动态代理无需开发人员手动编写代理类。动态代理在编译时并没有代理类存在，相反动态代理是在运行时，通过反射机制实现，并在运行期间提供给用户使用。在Java中实现动态代理机制，需要java.lang.reflect.InvocationHandler接口和java.lang.reflect.Proxy类的支持。

 动态代理的应用场景 

动态代理的应用就广泛了，以下举几个常见场景。

- Spring AOP，面向切面编程：通过动态代理将切点动态地织入到源码中。
> 注：可以参考我之前写的Spring AOP实现日志记录的文章

- Mybatis Mapper
- 接口级别的权限控制
...

 动态代理示例 

下面，我们通过动态代理实现方法调用次数的统计。

首先，我们定义一个测试类接口，往里面定义一个测试方法。

ITest.java

`java
package com.yeliheng.proxy.dynamic;

/
 * 测试类接口
 */
public interface ITest {
    void test();
}
`

接着我们来实现ITest接口。

在里面写一个test()方法，这个方法输出一串信息。

Test.java

`java

package com.yeliheng.proxy.dynamic;

public class Test implements ITest{

    @Override
    public void test() {
        System.out.println("测试方法被执行!");
    }
}

`

接着，我们的重点来了。我们使用动态代理模式，来统计test()方法被用户调用的次数。

开始写具体的处理逻辑。

MethodInvocationCountHandler.java

`java

package com.yeliheng.proxy.dynamic;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

/
 * 统计调用方法的次数
 */
public class MethodInvocationCountHandler implements InvocationHandler {

    private int count = 0;

    private final Object implementation;

    public MethodInvocationCountHandler(final Object implementation) {
        this.implementation = implementation;
    }

    public int getCount( ) {
        return count;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
        try {
            this.count++;
            System.out.println("测试方法被调用: " + this.count + "次");
            return method.invoke(implementation, args);
        } catch (final InvocationTargetException e) {
            throw e.getTargetException( );
        }
    }
}

`

在这个处理类中，我们实现了java.lang.reflect中的InvocationHandler，重写了invoke方法。并且，与静态代理相同，我们采用构造函数进行注入。invoke方法中，我们通过反射来获取对测试方法的调用。这样，我们就可以在main函数中使用我们写好的计数器了。

Main.java

`java

package com.yeliheng.proxy.dynamic;

import java.lang.reflect.Proxy;

public class Main {
    public static void main(String[] args) {
        ITest test = new Test();
        MethodInvocationCountHandler handler = new MethodInvocationCountHandler(test);
        ITest proxy = (ITest) Proxy.newProxyInstance(test.getClass().getClassLoader(), test.getClass().getInterfaces(),handler);
        proxy.test();
        proxy.test();
    }
}

`

调用方法与静态代理模式类似，只不过在动态代理中，我们没有显式声明Proxy代理类，而是通过反射的形式进行代理。在获取代理时，使用Proxy类提供的newProxyInstance来获取真实主题对象的引用。然后通过代理调用test()方法。

最终运行结果如下：

!output.png

这就是一个简单的动态代理使用例子。使用动态代理，我们能够为任意数量的真实主题生成代理，而无需重复定义代理类。

总结 #

本文列举了两个具体例子，分别是短信验证码的发送和方法调用的计数器，详细讲解了静态代理和动态代理的使用方法以及应用场景。

完整的源代码可参见：Github

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

Java设计模式再相识 (六)——代理模式

在项目开发的过程中，我们经常会遇到需要按照一定的步骤创建对象的需求，并且这个对象由多个子部件组成。例如一台完整的现代计算机硬件系统通常由：CPU、主板、内存条、硬盘、显卡、外设组装而成，用户通常选好需求配置就可以向电脑公司购买，而不需要用户亲自组装计算机，用户也无需关心内部的实现。在软件开发中，我们称这样的模式为建造者模式。这里以一个通俗易懂的例子引入，下文将详细讲解建造者模式以及其在软件开发中的具体应用。

> PS: 如果有阅读我前面的几篇文章会发现我文章的特点：例子都会以软件中的实际问题进行讲解，而不是随便举一个生活中的例子。

建造者模式 #

建造者（Builder）模式定义：建造者模式是将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式隐藏了复杂对象的创建过程，它把复杂对象的创建过程加以抽象，通过子类继承或者重载的方式，动态地创建具有复合属性的对象。

 建造者模式与工厂模式的区别 

建造者模式与工厂模式同为创建型模式，区别主要体现在以下几个方面：

- 建造者模式的关注点在类的组合，而工厂模式的关注点则是在类的创建。
- 创建对象的力度不同：建造者创建更复杂的对象，对象通常由多个部件组成，而工厂模式创建出的对象结构基本相同。
- 建造者模式构建对象具有顺序区别，不同顺序创建出来的对象大不相同。工厂模式创建的对象无法体现出顺序区别。

 建造者模式的组成结构 

建造者模式的结构如下：

1. 产品（Product）：建造者模式的产品是由多个部件组合而成的复杂对象。将由具体的建造者来创建其各个部件。
2. 抽象的建造者（Builder）：抽象建造者包含创建产品各个部件的抽象方法/接口，还准备了用于生成实例的方法。
3. 具体的建造者（ConcreteBuilder）：具体建造者负责实现由抽象建造者提供的接口。在具体的建造者中定义了各个部件实例的具体创建方法。此外，具体的建造者通常还会提供获取最终生成结果的方法。
4. 监工(导演-Director)：监工就像电影中的导演一样，指挥建造者完成复杂对象的构建。监工不直接关注产品的任何实现，它仅负责调用建造者对象中的方法完成对象创建。

 实际应用场景 

建造者模式在软件开发中的实际应用场景举例：

- 分页参数的构建：在实际项目中，我们通常需要使用分页来控制一页显示的数据。在分页返回的信息时，我们通常要返回给前端如下信息：当前页，一页显示多少内容，数据条目总计，总共分了多少页，下一页是第几页....等信息。这时，我们就很适合使用建造者模式来将这些信息按照一定的顺序构建出来，并一同返回。
- 数据库语句的拼接：在早些时候，ORM对象关系映射模型还没出现，我们操作SQL语句通常都使用字符串进行拼接，但这可能造成SQL注入漏洞的产生。所以，早些时候，我们使用建造者模式进行数据库SQL语句的构建，通过SqlBuilder拼接出复杂的语句，再提交给数据库进行执行。使用建造者模式拼接SQL语句而不是直接使用字符串拼接有助于防止注入漏洞的产生。

...

 示例 

在本节中，我们将动手实现一个ToStringBuilder，来满足将Java实体类中的成员变量转换为字符串拼接起来并输出。

我们首先准备好一个用户实体类：

User.java

`java
package com.yeliheng.builder;

/
 * 用户实体类
 */
public class User {

    private String username; //用户名

    private String password; //密码

    private String nickname; //昵称

    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;
    }
}
`

在上述实体类中，我们声明了用户名、密码、昵称三个成员变量。这时候，如果我们直接用toString()方法将这个类输出，输出结果如下所示：

!output.png

这显然不是我们预期的结果。这时，我们开始使用建造者模式将输出改造成预期结果。

我们创建一个抽象建造者Builder类。

Builder.java

`java

package com.yeliheng.builder;

public interface Builder {
    String append(User user);
}

`

抽象建造者类中提供了append方法，即将字符串进行拼接的方法。

接着，我们创建具体的建造者：ToStringBuilder.java

`java

package com.yeliheng.builder;

public class ToStringBuilder implements Builder{
    @Override
    public String append(User user) {
        StringBuffer buffer = new StringBuffer();
        buffer.append("用户名: " + user.getUsername() + "\n");
        buffer.append("密码: " + user.getPassword() + "\n");
        buffer.append("昵称: "+ user.getNickname() + "\n");
        return buffer.toString();
    }
}

`

在ToStringBuilder中，我们实现了append方法，将具体用户实体类中的用户名，密码以及昵称全部转换为String字符串，并通过StringBuffer进行拼接。

最后，我们开始使用具体的建造者。

Main.java

`java
package com.yeliheng.builder;

public class Main {
    public static void main(String[] args) {
        User user = new User();
        user.setUsername("yeliheng");
        user.setPassword("123456");
        user.setNickname("测试用户");
        System.out.println(user.toString());
    }
}
`
最终程序的输出结果如下：

!output.png

 对实例的引申 

我们使用建造者模式重写了内置的toString()方法，实现了用户实体类的输出。在本例中，User实体类充当了监工（导演）的角色，实体类中的toString()方法调用了ToStringBuilder的append()方法，User并不知道append()方法具体是怎样拼接字符串的，也无需知道。

在实际开发中，我们常常有类似本例的拼接字符串的需求，其实不需要自己实现，org.apache.commons.lang3就提供了一系列的工具类。其中，工具类大量使用了Builder模式，也是本例的来源。上述这个例子只是简单地实现了ToStringBuilder，实际的ToStringBuilder并没有这么简单。在真正的ToStringBuilder中，我们不能将实体类写死，而是需要动态地传入，并且ToStringBuilder返回的是自己的实例，以便于多次调用append()方法。它需要处理各种风格的输出以及对各种传入的数据类型进行处理。下图展示部分ToStringBuilder的真实代码作为了解，感兴趣的同学可以将工具包引入自行研究。

ToStringBuilder中的append方法: 

!WX20220214-215602@2x.png

ToStirngStyle中的append方法: 

!WX20220214-215650@2x.png

使用:

`java
@Override
public String toString() {
    return new ToStringBuilder(this, ToStringStyle.JSON_STYLE)
        .append("用户名", getUsername())
        .append("密码", getPassword())
        .append("昵称", getNickname())
        .toString();
}
`

继续回到我们的建造者模式，我们来分析一下建造者模式的优缺点：

 建造者模式的优缺点 

 优点 

- 良好的封装性：可以将构建与表示分离。这也是建造者模式的核心定义。
- 良好的拓展性：建造者之间相互独立，有利于降低系统的耦合性，提高可拓展性。
- 使用者无需知道类的组成部分，建造者可对产品创建的步骤进行封装，不会影响其他模块的创建，这也提高了系统的内聚性。

 缺点 

- 一个类的组成如果发生了修改，则建造者也要同步修改。

总结 #

本文详细介绍了建造者模式，及其在实际开发中的应用场景，并且引出了apache工具类的实现。有助于深入理解建造者模式。

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

建造者模式同样属于创建型模式，当你需要按照一定的步骤组装对象时，建造者模式能帮你解决问题。本文将以Java为例，带你重温GoF设计模式之建造者模式，并深入理解建造者模式及其应用场景。

Java设计模式再相识 (五)——建造者模式

上节我们详细介绍了工厂方法模式，解决了复杂对象的创建问题。这次，我们的需求再次升级，我们需要生成具有层级关系的具体产品，并且同一层级具有由多个具体工厂生产的具体产品。对比工厂方法模式，工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品。

抽象工厂模式 #

抽象工厂（Abstract Factory）模式：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，同样属于对象创建型模式。

抽象工厂模式的结构与工厂方法类似，只不过在原有的基础上拓展了层级概念。

- 抽象工厂（AbstractFactory）：提供了产品的抽象类或接口。
- 具体工厂（ConcreteFactory）：具体的创建类，实现具体生产产品的方法。
- 抽象产品（Product）：产品的抽象创建类。
- 具体产品（ConcreteProduct）：将抽象产品进行实现。

 实际应用场景 

换行符：在不同操作系统中，换行符也各有不同。像在Windows下，换行符是\r\n，而在Linux下则是\n。在这个场景中，操作系统充当一个超级工厂角色，Windows和Linux则是超级工厂下的具体工厂，换行符则是它们生产的具体产品。

数据库：不同的数据库有自己的数据库方言，但它们的基础都是SQL语言。

...

 示例 

在本文中，与上篇一样，我们还是采用日志工厂进行举例。

在抽象日志工厂中，我们有一个超级工厂，也就是日志工厂。日志工厂下面有两个小工厂，分别是Log4j工厂和Logback工厂，这两个工厂可以生产出不同风格的日志。同时我们日志的产品有：直接输出到控制台的日志，写入文件的日志。两个工厂实现日志的逻辑各不相同。下面我们开始写具体的代码。

首先我们先来创建超级工厂类。

Factory.java

`java

package com.yeliheng.factory.abstractfactory;

/
 * 超级工厂
 */
public interface Factory {

    public ConsoleLogger consoleLogger();

    public FileLogger fileLogger();

}

`

超级工厂类中提供了两个接口：分别是控制台日志接口和文件接口。它告诉下面的工厂，只能生产这两种接口规范的产品。具体怎么进行生产，超级工厂并不关心。

然后，我们创建两家工厂，分别是Log4j工厂和Logback工厂。

Log4jFactory.java

`java

package com.yeliheng.factory.abstractfactory;

/
 * Log4j工厂
 */
public class Log4jFactory implements Factory{
    @Override
    public ConsoleLogger consoleLogger() {
        return new Log4jConsoleLogger();
    }

    @Override
    public FileLogger fileLogger() {
        return new Log4jFileLogger();
    }
}

`

LogbackFactory.java

`java

package com.yeliheng.factory.abstractfactory;

/
 * Logback工厂
 */
public class LogbackFactory implements Factory{

    @Override
    public ConsoleLogger consoleLogger() {
        return new LogbackConsoleLogger();
    }

    @Override
    public FileLogger fileLogger() {
        return new LogbackFileLogger();
    }
}

`

在这两家工厂中，我们实现了超级工厂提供的两个方法，并让其返回自身生产的具体产品类。

我们先来实现抽象的产品类。

ConsoleLogger.java

`java
package com.yeliheng.factory.abstractfactory;

/
 * 抽象产品类: 控制台日志
 */
public interface ConsoleLogger{

    //日志级别

    void debug(String text);

    void info(String text);

    void warning(String text);

    void error(String text);

}

`

FileLogger.java

`java

package com.yeliheng.factory.abstractfactory;

/
 * 抽象产品类: 文件日志
 */
public interface FileLogger{

    //日志级别
    void debug(String text);

    void info(String text);

    void warning(String text);

    void error(String text);
}

`

这两个抽象产品类都提供了四种不同级别的日志输出，分别是debug，info，warning，error。你会发现它们内容相同。在实际开发中，我们需要根据实际需求对其代码进行修改。这里为了方便演示与理解，仅仅通过名字和输出来区别“输出到控制台的日志”和“输出到文件的日志”，并没有真正使用文件流来将日志保存到磁盘。

现在，我们可以开始实现具体的产品类了。

Log4jConsoleLogger.java

`java
package com.yeliheng.factory.abstractfactory;

/
 * 具体产品类
 */
public class Log4jConsoleLogger implements ConsoleLogger{
    @Override
    public void debug(String text) {

    }

    @Override
    public void info(String text) {
        System.out.println("--[INFO]-- Log4j输出的[控制台]日志: " + text);
    }

    @Override
    public void warning(String text) {

    }

    @Override
    public void error(String text) {

    }
}

`

Log4jFileLogger.java

`java
package com.yeliheng.factory.abstractfactory;

/
 * 具体产品类
 */
public class Log4jFileLogger implements FileLogger{
    @Override
    public void debug(String text) {

    }

    @Override
    public void info(String text) {
        System.out.println("--[INFO]-- Log4j输出的[文件]日志: " + text);
    }

    @Override
    public void warning(String text) {

    }

    @Override
    public void error(String text) {

    }
}

`
在具体产品类中，我们通过输出风格的不同来区别是Log4j工厂还是Logback工厂生产的产品。
LogbackConsoleLogger.java和LogbackFileLogger.java的内容与Log4j的具体产品内容基本相同，仅仅只有输出的不同。完整的代码可前往Github获取。

准备好了工厂和产品，这个时候客户来了。客户要开始使用工厂生产出来的产品了。

我们开始编写Main类，以便于使用我们刚才写好的代码，让工厂开始工作。

Main.java

`java

package com.yeliheng.factory.abstractfactory;

public class Main {
    public static void main(String[] args) {
        Factory log4jFactory = new Log4jFactory();
        ConsoleLogger consoleLogger = log4jFactory.consoleLogger();
        consoleLogger.info("测试日志");

        FileLogger fileLogger = log4jFactory.fileLogger();
        fileLogger.info("文件测试");

        Factory logbackFactory = new LogbackFactory();
        ConsoleLogger consoleLogger1 = logbackFactory.consoleLogger();
        consoleLogger1.info("测试日志");

        FileLogger fileLogger1 = logbackFactory.fileLogger();
        fileLogger1.info("文件测试");

    }
}

`

在Main方法中，我们分别对两家工厂生产的同一级别的四种产品进行测试。最后我们查看运行结果。

!output.png

从运行结果可以看出，两家日志工厂都正确地输出了各自生产的日志，这就是抽象工厂模式的具体实现。

 抽象工厂模式的优缺点 

优点：
- 能够生成复杂的，多个层级的产品结构。
- 隔离了具体类的生成：系统不用关心具体产品如何创建，组合。这在项目开发中能够维持良好的拓展性。

缺点：
- 层级较为复杂带来的就是系统复杂性的提高。
- 开闭原则的倾斜性：增加新的工厂和产品等级结构容易，增加新的同级的产品需要改变工厂代码。

总结 #

抽象工厂模式在简单工厂和工厂方法的基础上进行升级，最重要的是类层级结构的产生，可以使调用者无需关心什么对象被创建，提高系统的内聚性。

本例完整的源码可参见: Github

在复杂项目中，如何优雅地生成多个等级的对象？本文将以Java为例，带你重温GoF设计模式之抽象工厂模式，并深入理解抽象工厂模式及其应用场景。

标签：设计模式