如果你想让额定工作电压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设计模式之抽象工厂模式，并深入理解抽象工厂模式及其应用场景。

Java设计模式再相识 (四)——抽象工厂(Abstract Factory)模式

在项目的开发中，我们经常会遇到需要创建复杂对象的场景，例如一个参数繁多的类的构造函数。这时如果我们不使用任何设计模式进行开发，项目将变得十分复杂，面对常常变动的需求，我们可能需要一个一个修改参数，并在任何引用该类的地方都做一次修改，最后只会变得乱成一团无法维护。那么该如何解决这个问题呢？

答案是使用工厂模式。在需要创建复杂对象，并频繁使用时，我们就可以选择工厂模式。

工厂模式的三种实现形式 #

工厂模式有三种实现形式

- 简单工厂（静态工厂）
- 工厂方法（本节核心）
- 抽象工厂

> 注：简单工厂并不算在GoF 23种设计模式中

本节，我们将深入理解工厂方法模式及其应用。

简单工厂（静态工厂） #

在介绍工厂方法模式之前，我先对简单工厂进行介绍。在简单工厂模式中，创建实例的方法通常为静态方法，因此简单工厂模式又被成为静态工厂方法。简单工厂只有一个具体的工厂类，专门用于生产特定专一的产品，在需要生产多种产品时，需要将多个产品定义到同一个工厂中进行生产。简单工厂名副其实，十分简单。这样的好处就是产品创建方便，客户直接提需求，工厂直接实现，不需要经过任何产品线。但问题也来了，在需要大量创建不同产品时，简单工厂就会变得“不堪重负”。回归到软件中，简单工厂会增加系统的复杂性，在多个产品的情况下，单个类职责过重，软件将变得难以维护。每增加一个产品就要增加一个工厂类，违背了“开闭原则”。

 简单工厂的示例 

我们有苹果树和梨树和一家工厂，这家工厂要负责将水果树上的所有水果都摘下来。

`java

package com.yeliheng.factory.simplefactory;

public class Main {
    public static void main(String[] args) {
        Apple apple = (Apple) SimpleFactory.make(0);
        Banana banana = (Banana) SimpleFactory.make(1);
        apple.show();
        banana.show();
    }

    //水果产品
    public interface Fruit {
        void show();
    }

    //具体产品
    static class Apple implements Fruit {
        public void show() {
            System.out.println("苹果树上长苹果...");
        }
    }

    //具体产品
    static class Banana implements Fruit {
        public void show() {
            System.out.println("香蕉树上长香蕉...");
        }
    }

    //工厂生产
    static class SimpleFactory {
        public static Fruit make(int kind) {
            switch (kind) {
                case 0:
                    return new Apple();
                case 1:
                    return new Banana();
            }
            return null;
        }
    }
}

`

通过代码示例我们可以看到每生产一种具体的水果，就要定义一个新的静态产品类让水果能被工厂生产。工厂类的代码将会随着产品的增加越来越复杂。

为了解决这个问题，工厂方法（Factory Method）模式出现了。

工厂方法 #

工厂方法模式在简单工厂模式的基础上进一步抽象，可以使系统拓展新的具体类时，原来的工厂代码不必修改，满足开闭原则。拓展新的需求，创建新产品，只需要在原来的基础上增加一个工厂类，这样就可以有多个工厂为我们服务。并且上层应用只需了解抽象的产品类，无需对其他类进行拓展。这也同时满足了迪米特法则、依赖倒置原则和里氏替换原则。但工厂方法模式同样存在缺点。它将会让工厂类数目繁多，降低系统代码的可读性。并且在抽象产品中，只能产出一种具体产品。（这个问题可以使用抽象工厂解决，下节介绍）。

工厂方法模式由以下结构组成：

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

 实际应用场景 

- 日志工厂
- 文件存储
...

 示例 

我们来实现一个日志工厂，该日志工厂具有以下三个功能：
1. 打印日志到控制台
2. 打印日志到文件

我们按照上文所述的结构一一实现工厂方法：

1. 抽象产品

Logger.java

`java

package com.yeliheng.factory.factorymethod;

/
 * 日志产品的抽象
 */
public interface Logger {
    //日志级别
    void debug();

    void info();

    void warning();

    void error();

}

`

我们在抽象产品中定义了四个产品接口，可对应四种不同级别的日志。

2. 抽象工厂

LoggerFactory.java

`java

package com.yeliheng.factory.factorymethod;

public interface LoggerFactory {
    Logger getLogger();
}

`

在抽象工厂中，我们去使用Logger，定义一个getLogger()方法来便于待会具体工厂获取Logger实例。

3. 具体产品

我们实现两个具体产品类，一个是输出到控制台的产品类，一个是输出到文件的产品类。这里为了代码的简洁，就不详细地写出输出到文件的逻辑，仅使用输出进行简单举例。

ConsoleLogger.java

`java
package com.yeliheng.factory.factorymethod;

public class ConsoleLogger implements Logger{
    @Override
    public void debug() {

    }

    @Override
    public void info() {
        System.out.println("[INFO] 这条日志被输出到[控制台]");
    }

    @Override
    public void warning() {

    }

    @Override
    public void error() {

    }
}
`

FileLogger.java

`java
package com.yeliheng.factory.factorymethod;

public class FileLogger implements Logger{
    @Override
    public void debug() {

    }

    @Override
    public void info() {
        System.out.println("[INFO] 这条日志被输出到[文件]");
    }

    @Override
    public void warning() {

    }

    @Override
    public void error() {

    }
}

`

4. 实现具体的工厂

ConsoleLoggerFactory.java

`java
package com.yeliheng.factory.factorymethod;

/
 * 具体工厂
 */
public class ConsoleLoggerFactory implements LoggerFactory{
    @Override
    public Logger getLogger() {
        return new ConsoleLogger();
    }
}
`

我们重写了实现了抽象工厂：LoggerFactory，并重写了getLogger方法，让其返回一个ConsoleLogger实例。

FileLoggerFactory.java

`java

package com.yeliheng.factory.factorymethod;

public class FileLoggerFactory implements LoggerFactory{
    @Override
    public Logger getLogger() {
        return new FileLogger();
    }
}

`

原理相同。

5. 最后，我们可以开始使用我们通过工厂方法模式创建的日志工厂了。

Main.java

`java
package com.yeliheng.factory.factorymethod;

public class Main {
    public static void main(String[] args) {
        //输出到控制台
        LoggerFactory consoleLoggerFactory = new ConsoleLoggerFactory();
        Logger logger1 = consoleLoggerFactory.getLogger();
        logger1.info();
        //输出到文件
        LoggerFactory fileLoggerFactory = new FileLoggerFactory();
        Logger logger2 = fileLoggerFactory.getLogger();
        logger2.info();

    }
}

`
可以看到最终输出如下：

!output.png

细心的你可能会发现，这个写法与slf4j日志库的写法十分相似。没错，查看slf4j源码可以发现，其使用了大量工厂模式实现强大的日志框架。

小结 #

到此，我们使用工厂方法模式完成了一个简单的日志工厂，下节我们将使用抽象方法模式继续完善本节的例子。

源码参考：Github

在项目中，如何做到对象的创建与使用分离？本文将以Java为例，带你重温GoF设计模式之工厂方法模式，并深入理解工厂方法模式及其应用场景。

Java设计模式再相识 (三)——工厂方法(Factory Method)模式

当你的系统存在相同或者相似对象需要创建，你可能会想到使用new 对象名() 来创建。但如果你的系统存在大量相同对象需要创建时，这样做会显得效率低下，并且代码将杂乱无章，你需要在构造函数中使用大量类名来进行实例化。这时，我们可以采用原型模式来进行优化，提高执行效率。例如复印机只需要简单的配置就可以复印出大量材料，这就是典型的原型模式的体现。

原型模式介绍 #

原型(Prototype)：用一个已经创建的“原型对象”进行复制，得出与原型相同或者相似的新对象。原型模式和上节的单例模式同样属于创建型模式。它很少单独使用，经常与其他设计模式配合使用（例如：它可以与Command命令模式配合使用，便于复制Command模式中出现的命令）。但作为基础，我们也必须掌握原型模式。

应用场景 #

我相信你最关心什么时候需要用到原型模式，这里我列举出几种可以使用原型模式的场景供你参考：

- 相同或相似对象繁多，无法将他们整合到唯一一个类中。
- 一个类调用了另外一个类，两个类之间存在耦合，你想把他们解耦，在不修改另一个类的情况下改变职责。
- 难以根据类来生成实例时。

 举例 

下面我们来根据一个实际的例子实现原型模式。

例子：假设你有一台打印机，它可以为你打印大量的文件，并且支持各种纸张的样式。现在，你需要让它为你打印大量A4和A3版本的Hello,World。请使用原型模式实现它。

首先我们定义打印机原型：

Printer.java

`java
package com.yeliheng.prototype;

/
 * 打印机原型
 */
public class Printer implements Cloneable {

    private String paperType; //纸张类型

    private String content; //打印内容

    public Printer(String paperType, String content) {
        this.paperType = paperType;
        this.content = content;
        System.out.println("打印机准备就绪！");
    }

    public String getPaperType() {
        return paperType;
    }

    public void setPaperType(String paperType) {
        this.paperType = paperType;
    }

    public String getContent() {
        return content;
    }

    public void setContent(String content) {
        this.content = content;
    }

    public void display() {
        System.out.println(" 纸张类型: " + paperType + " \n 打印内容: " + content);
    }

    @Override
    public Printer clone() {
        try {
            return (Printer) super.clone();
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }
}
`

Printer原型的实现代码很简单，我们具体来关注对Cloneable接口的实现。在Printer类中，我们实现了java.lang包提供的Cloneable接口，并重写了clone()方法，在clone()方法内，我们试图捕获CloneNotSupportedException异常。这是因为我们必须保证被复制的对象必须实现java.lang.Clonable接口，否则对象将无法被克隆。细心的你可能会发现Cloneable接口中并没有clone()方法的相关定义。这是因为clone()方法被定义在java.lang.Object中，而Object类是所有Java类的父类。因此所有Java类都继承了clone()方法。像Cloneable接口很容易让人误认为Cloneable接口中声明了clone()方法，其实这是错误的。Clone接口中什么都没有，它只是起到告诉程序可以调用clone方法的作用。

写完了打印机原型，我们现在就开始让它工作，让它为我们复制出不同纸张类型的Hello,World。

Main.java

`java

package com.yeliheng.prototype;

/
 * 原型模式
 */
public class Main {
    public static void main(String[] args) {

        Printer obj1 = new Printer("A4","Hello,World");
        obj1.display();

        Printer obj2 = (Printer) obj1.clone(); //克隆！
        obj2.setPaperType("A3");
        obj2.display();
    }
}

`

我们先用传统的方式实例化了Printer类，让它打印一张A4的Hello,World。然后我们用克隆的方式：obj1.clone()，让它打印出一张A3的相同内容的纸。最后的输出结果如下：

!输出结果

这时，我们就实现了一个原型模式。本例中的克隆方式称为浅克隆。

>请注意：Cloneable接口破坏了单例模式，如果是单例类，又实现了Cloneable接口，那么该类就可以调用clone方法创建另外的实例，因此破坏了单例模式。

浅克隆 #

浅克隆：创建一个新对象，新对象的属性和原来对象完全相同，对于非基本类型，浅克隆只会将实例的引用复制。例如，当字段中保存的是数组时，如果使用clone()方法进行克隆，则只会将数组的引用复制，并不会复制数组内的元素。浅克隆默认使用super.clone()来实现。

深克隆 #

深克隆：创建一个新的对象，属性中引用的其他对象也将被克隆，不再指向原对象地址，即在内存中开辟新的空间。

如果你需要更复杂的功能，例如复制所有非基本类型的引用和值，则需要以下步骤：

1. 创建实例对象：通过clone()方法创建原型类的实例，这个步骤与浅克隆相同。
2. 克隆引用的成员：调用原型类对象成员的clone()方法，创建新的成员对象，将新的成员对象赋值给克隆出的原型模式的对象。（类似于递归调用）
3. 返回新对象：返回clone()创建的原型对象。

思考：你可以尝试着实现一个包含数组对象的深克隆。

总结 #

本文仅举一个简单的例子展现原型模式，在实际开发中，原型模式需要根据具体情况决定是否使用，例如上文描述的几种应用场景。熟练掌握原型模式，在后面需要与其他设计模式一起使用时，你就能够轻松驾驭。

源码参考：GitHub

当你的系统存在大量相同对象需要创建，使用原型模式能够为你高效地创建对象。本文将以Java为例，带你重温GoF设计模式之原型模式，并深入理解原型模式以及应用场景。

Java设计模式再相识 (二)——原型模式

> 当你想在一个庞大的工程中，确保整个程序只存在一个唯一的实例，并且保证在任何情况下，新的实例都不会被创建，这时候，单例模式将是你的不二之选。

我们在使用Windows操作系统时，是否曾注意到任务管理器，回收站等系统应用始终只能打开一个窗口，这就是单例模式的类比。接下来，我们将动手实现一个单例模式的程序。在开始之前，我们先来熟悉单例模式的基本概念。

基础篇 #

 介绍 

单例（Singleton）模式的定义：一个类只允许拥有一个实例。

单例模式通常有两种实现形式：饿汉式，懒汉式。在基础篇中，我将详细介绍饿汉式单例模式。

何为饿汉式？顾名思义，就是在类加载时就创建一个单例，这样能够保证在调用getInstance()方法之前这个单例就已经存在。

现在，就让我们来编写代码模拟实现一个Windows任务管理器，让它只能存在一个。

 示例-模拟任务管理器 

我们新建一个名为Singleton.java的文件，代码内容如下: 

Singleton.java

`java
package com.yeliheng.singleton;

public class Singleton {
    private static final Singleton singleton = new Singleton();

    private Singleton() {
        System.out.println("任务管理器已打开！");
    }

    public static Singleton getInstance() {
        return singleton;
    }
}

`

在Singleton类中，我们定义了static字段的成员变量singleton，并将其初始化为Singleton类的实例。然后我们定义了一个私有构造函数Singleton，打印提示。使用private修饰符可以防止从Singleton类以外的代码调用构造函数，从而单例模式将失去意义。

接着我们定义getInstance()方法，就可以让外部程序以只读的方式获取到Singleton类的唯一实例。(通常情况下，我们采用getInstance作为方法名。)

Main.java

`java

package com.yeliheng.singleton;

public class Main {

    public static void main(String[] args) {

        Singleton obj1 = Singleton.getInstance();

        Singleton obj2 = Singleton.getInstance();

        if(obj1.equals(obj2)) {
            System.out.println("obj1和obj2是同一个实例，任务管理器只能创建一个！");
        }
    }
}

`
在Main函数中，我们定义obj1和obj2两个变量，这两个变量都去创建两次Singleton实例。然后我们使用if语句来判断，这两个实例是否是同一个实例。代码十分简单，我们一起来看看运行结果。

运行结果如下：

!QQ20220210-214108@2x.png

显而易见，两个实例是同一个实例，我们的Singleton只被创建了一次。

饿汉式单例我们就介绍到这里，接下来，我们开始介绍懒汉式单例。

进阶篇 #

 懒汉式单例 

懒汉式单例在类加载时不会生成单例，只有当第一次调用getInstance()方法时才去创建这个单例。代码如下: 

`java
package com.yeliheng.singleton;

public class LazySingleton {
    
    private static LazySingleton lazySingleton = null; //创建一个空的懒汉式单例

    private LazySingleton() {

    }
    
    public static LazySingleton getInstance() {
        if (lazySingleton == null) {
            lazySingleton = new LazySingleton();
        }
        return lazySingleton;
    }
}

`

在这个例子中，代码与前面的大同小异，就是在初始化lazySingleton变量时，没有像饿汉式单例那样立即实例化，而是指定一个null，当需要获取Instance实例时，再进行实例化。这样做，可以在大型计算场景中，节省内存，按需加载。

不知道聪明的你有没有注意到这样做的问题。在上面这个代码中，存在线程安全问题。在多线程程序的条件下，会出现LazySingleton还未创建完成的情况下，另一个线程又去访问调用LazySignleton，造成实例被创建多次的情况，这样它就不再是一个单例模式了。我们现在对程序进行改进：

`java

package com.yeliheng.singleton;

public class LazySingleton {

    private static volatile LazySingleton lazySingleton = null; //创建一个空的懒汉式单例

    private LazySingleton() {

    }

    public static synchronized LazySingleton getInstance() {
        if (lazySingleton == null) {
            lazySingleton = new LazySingleton();
        }
        return lazySingleton;
    }
}

`
没错，只需要在变量出增加volatile关键字，并在静态成员方法处增加一个同步锁，就可以完美解决这个问题，保证线程安全。这样，全局程序将不可能出现多个实例。

 总结 

单例模式是设计模式中常用的模式之一。单例模式的形式常分为饿汉式和懒汉式。饿汉式的优点是创建起来简单，并且天然线程安全。缺点是在大量单例存在时，将造成资源浪费。懒汉式的优点是性能较好，按需加载对象，能够让内存空间被较佳利用。缺点是创建相对于饿汉式复杂，在多线程的场景下，对多线程不熟悉或稍不注意容易出现线程安全问题。

源码参考：GitHub

本文将以Java为例，带你重温GoF设计模式之单例模式，并深入理解单例模式的创建方法以及应用场景。

Java设计模式再相识 (一)——单例模式

引言

当你在开发一个后台管理系统时，突然遇到需要记录用户操作日志的需求，你会采取什么样的方法？解决此问题的方法有很多种，如：在每个地方都写一遍打印日志的逻辑（这显然是不明智的）、使用代理模式（AOP底层原理）...

本文将带领你使用较理想的解决方案处理这个需求——使用AspectJ提供的AOP库实现日志的记录，并配合Java的Annotation注解来实现在控制器上记录日志。

AOP介绍

在开始前，我将简单介绍AOP的一些概念，如果你对这些概念完全陌生，建议先上网了解相关概念，再继续阅读。

AOP，面向切面编程，即Aspect Oriented Programming。

- Aspect：切面，类似于Java中的类声明，是对系统中横跨多个类的关注点进行模块化封装

- Joinpoint：连接点，程序执行过程中的一个“点”，例如：方法的执行或异常的处理。在Spring AOP中，一个连接点总是代表一个方法的执行。

- Pointcut：切入点，即一组连接点的集合；

- Advice：通知，定义了将会织入到 Joinpoint 的具体逻辑，通过@Before、@After、@Around等注解来区别在JointPoint之前、之后等位置执行代码

- Weaving：织入，织入指的是将Advice连接到Pointcut指定的Joinpoint处的过程

- Interceptor：拦截器，是一种实现Advice（通知）的方式；

- Target：目标对象，即符合切入点所指定的条件被织入Advice的对象。

以上术语，你可能会感到些许困惑，不过没关系，我们开始进入到正式的Coding，一步一步实现功能后，再回来此部分看这些概念，就会豁然开朗。

Coding——开始实现日志模块

 引入依赖 

以SpringBoot为例，首先我们从Maven中央仓库引入AOP所需的依赖。在你的pom.xml中添加以下代码：

`xml
		
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-aop</artifactId>
		</dependency>
`

 定义注解 

定义注解目的在于：之后需要打印日志的地方，只需要@Log("模块名称","业务类型")即可。

---

我们使用IDEA右键->New->Java Class->Annotation，文件名为Log.java。代码片段如下：

`java

@Target({ ElementType.PARAMETER, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
public @interface Log {

    /
     * 模块名称
     */
    public String moduleName() default "";

    /
     * 业务类型
     */
    public int businessType() default BusinessType.OTHER; 
    //此处业务类型可以自己定义，完整代码可参考文末本仓库Github
}

`
在Log注解中，我们定义了注解能接收的两个参数：模块名称、业务类型。并将Target目标指定为METHOD方法，即方法注解。

@Retention(RetentionPolicy.RUNTIME)表明此注解不仅被保存到class文件中，在JVM加载class文件之后，此注解仍然存在。

 编写切面类 

日志切面的核心代码，这个类中的代码将动态地注入到注解所在方法的横截面中，并实现日志的记录。

`java

@Component
@Aspect
public class LogAspect {

    @Pointcut("@annotation(com.yeliheng.blogcommon.annotation.Log)")
    public void pointcut() {}

    @AfterReturning(pointcut = "pointcut()", returning = "jsonResponse")
    public void doReturningLogRecord(JoinPoint joinPoint, Object jsonResponse) {
        recordLog(joinPoint,null,jsonResponse);
    }

    @AfterThrowing(value = "pointcut()", throwing = "e")
    public void doThrowingLogRecord(JoinPoint joinPoint, ApiException e) {
        recordLog(joinPoint,e,null);
    }

    private void recordLog(JoinPoint joinPoint, ApiException e, Object jsonResponse) {
        Log log = getAnnotation(joinPoint);
        if(log == null) {
            return;
        }
        //TODO: 记录日志的具体逻辑 如：获取各种信息，写入数据库等操作...

    }

    /
     * 通过反射获取注解
     */
    private Log getAnnotation(JoinPoint joinPoint) {
        Signature signature = joinPoint.getSignature();
        MethodSignature methodSignature = (MethodSignature) signature;
        Method method = methodSignature.getMethod();
        if(method != null) {
            return method.getAnnotation(Log.class);
        }
        return null;
    }
   
}

`

要实现切面类，我们需要在类前加入两个注解：@Component,@Aspect，以供Spring IoC容器进行管理。Spring的IoC容器读取到Aspect注解时，会自动查找带有@Aspect的Bean，然后根据@AfterReturning、@AfterThrowing等拦截器注解把AOP注入到特定的Bean中。

拦截器注解说明：
- @AfterReturning: 当方法正常返回时会被此拦截器拦截。
- @AfterThrowing: 当方法运行过程中有异常抛出时，会被此拦截器拦截。

在doReturningLogRecord和doThrowingLogRecord，我们都传入一个joinPoint，并在recordLog方法中通过joinPoint获取我们定义的自定义注解——@Log，并可以通过反射从连接点获取到方法名称和类名。

弄清楚了拦截器方法的作用，我们就可以在recordLog方法中编写具体的记录日志的逻辑。如：记录操作时间，操作人，操作地点等，并把这些信息写入数据库中。

 开始使用 

编写完切面类后，不出意外的话你的自定义注解的日志已经可以正常使用并且记录用户日志了。但是我们要如何使用它呢？

`java

    @Log(moduleName = "新增用户",businessType = BusinessType.INSERT)
    @PostMapping
    public CommonResponse<Object> add(@Validated @RequestBody User user) {
        userService.insertUser(user);
        return CommonResponse.success();
    }

`

使用的方法非常简单，只需要在对应的控制器方法上，加上@Log("模块名称","业务类型")，JVM就会通过自身的动态代理功能将对应的代码编译成字节码并织入到对应的横截面中。这就是AOP面向切面编程的最佳实践。

总结 #

本文介绍如何使用Spring AOP实现对用户操作日志的记录，如需深入了解Spring AOP运行原理，请前往Spring官网，查阅Spring手册或通过源代码进行深入分析。

完整代码参见：Github

本文将使用AOP面向切面编程，基于SpringBoot下的AspectJ实现对用户操作日志的记录。

Spring AOP的最佳实践：在你的系统中记录用户的操作日志

> Yeliheng-Blog文档在GitHub、Yeliheng的技术小站上同步更新，开源仓库地址: https://github.com/yeliheng/yeliheng-blog
>
> 欢迎Star，Issue，Pull requests以及任何对本项目的贡献。开发不易，感谢支持！

系统介绍

这个开源仓库是Yeliheng的技术小站的前后端实现。Yeliheng-Blog是一个基于SpringBoot + Vue3开发的前后端分离的完整博客系统。它并不仅仅是一个简单的博客系统，更是一个后台权限管理系统，通过模块化使其具有高拓展性，可拓展成任何您想要的管理系统，例如文章系统，OA办公系统，仓库管理系统等...

 特性

- 轻量化系统，无外部框架的重度依赖

- 良好的可拓展性

- 响应式前端网页，完全适配移动端以及不同分辨率设备

- 基于RBAC模型的权限管理系统

- 优质的用户体验

  ...

 在线地址

后台演示功能暂未完成，目前仅开放前台展示，后台系统可自行搭建体验。

前台演示地址: https://www.yeliheng.com

功能详解

 后台

 目前已有功能

- 文章管理：实现文章的增删改查，以及文章分类、标签，隐私性的设置。
- 用户管理：用户登录、注册以及管理员对用户的增删改查操作。
- 角色管理：对角色系统的增删改查以及为用户分配多个角色。
- 权限管理：可为不同角色分配所需的不同权限，支持菜单权限，资源权限，按钮权限。
- 菜单管理：为角色分配菜单权限，以及前端菜单的动态路由处理，支持放置外链。
- 字典管理：对前端需要进行切换的状态字典进行动态管理。
- 站点统计：目前仅实现对文章字数，阅读时长及字数的统计，后续将以模块化形式实现站点的完整统计功能。
- 数据库监控：基于Druid的数据库可视化监控。

 正在开发中的功能

- 评论管理模块

- 完整的站点统计模块

- 定时备份模块的开发

- API接口文档

---

 前台

 目前已有功能

- 基于Markdown和Github风格的文章查看器

- 按照分类索引文章

- 按照标签索引文章

- 基于Three.js实现的Header

- 站点信息的显示

- 关于页面

 正在开发的功能

- 评论模块

- 日夜间模式的切换

- 站点统计模块

---

工程结构

`
yeliheng-blog
├── blog-common    --  后端系统通用模块（封装各种工具类、公共常量、异常类等）
├── blog-framework --  后端系统框架层（封装框架相关工具，如权限工具，框架配置文件，安全相关类）
├── blog-system    --  博客系统核心业务层（服务，数据库访问）
├── blog-web       --  博客系统API控制器（controller）
└── blog-vue       --  博客系统前端模块（Vue3）
    ├── admin   --  博客系统前端后台模块
    └── blog    --  博客系统前端前台模块
`

!模块图

技术栈

| 技术                 | 说明                |
| -------------------- | ------------------- |
| SpringBoot           | 容器+框架           |
| SpringSecurity       | 认证/权限框架       |
| MyBatis              | ORM框架             |
| RabbitMQ             | 消息队列            |
| Redis                | 分布式缓存          |
| Nginx                | 静态资源服务器      |
| Docker               | 应用容器引擎        |
| Jenkins              | 自动化部署工具      |
| Druid                | 数据库连接池        |
| OSS                  | 对象存储            |
| JWT                  | JWT登录支持         |
| PageHelper           | MyBatis物理分页插件 |
| Swagger-UI           | 文档生成工具        |
| Hibernator-Validator | 验证框架            |
| Vue3                 | 渐进式js框架        |
| Sass                 | css扩展语言         |
| Element-UI           | 饿了么UI库          |
| Markdown-it          | markdown解析工具    |

搭建教程

 开发环境

在开始之前，请确认您的开发环境，尽量与此处保持一致，以免出现意料之外的问题。

 后端

| 开发环境 | 版本   |
| -------- | ------ |
| JDK      | 1.8  |
| JRE      | 1.8  |
| MySQL    | 5.7  |
| Redis    | 6.x  |

 前端

| 开发环境 | 版本     |
| -------- | -------- |
| Vue      |  3     |
| Node.js  | 14.x |
| npm      | 6.x  |

 快速开始

 后端

1、搭建如上表格所示的开发环境并确保所有环境处于正常运行状态。（具体过程此处不做赘述，可自行查阅相关资料）

2、克隆本项目

`
git clone https://github.com/yeliheng/yeliheng-blog.git
`

3、导入idea或其他IDE，等待Maven导入所有的包。（此过程可能需要一些时间，部分国外仓库加载较慢，建议使用国内镜像源，具体步骤可自行在搜索引擎上查看）

4、在blog-web包的resource目录下新建配置文件，文件名为：application-dev.yml，并将application-example.yml中的内容复制到刚刚创建的application-dev.yml中，并将datasource中的数据源修改为自己的数据库信息。

5、导入数据库

将项目sql文件夹中的所有.sql文件导入到数据库中。

6、准备完成，开始运行项目！

当您看到如下提示，代表项目已成功运行。

!成功

 前端

1、进入本项目中的blog-vue文件夹中，前端分为admin和blog两个模块，此处以admin模块为例进行说明。

2、我们首先进入admin文件夹，在admin文件夹中新建文件：.env.development（重要！），并将 .env.example 中的内容复制到刚刚创建的 .env.development中，并将VUE_APP_BASE_API地址修改为后端地址。若您没有改动后端地址则无需更改。

3、执行如下指令安装所需依赖：

`
npm install
`

4、等待上述指令执行完成后，执行以下指令：

`
npm run serve
`

5、项目成功运行，开始访问吧！

管理员账号：admin

管理员密码: admin123

blog模块的安装方法与上述过程完全相同

项目截图

!首页

!文章

!后台

!权限管理

Yeliheng-Blog已开源，欢迎二次开发！本篇文章将详细介绍本站系统以及搭建教程。

标签：Java