[Java知识库] Spring运用到的几种设计模式

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> Java知识库 -> Spring运用到的几种设计模式 -> 正文阅读

[Java知识库]Spring运用到的几种设计模式

一、什么是Spring?

Spring是一个轻量级的IOC和AOP容器框架是为JAVA应用程序提供基础性服务的一套框架，目的是用于简化应用程序的开发，它使得开发者只需要关心业务需求。

在spring中主要用到的设计模式有：工厂模式、单例模式、代理模式、模板模式、观察者模式、适配器模式。

工厂模式

工厂顾名思义就是创建产品，根据产品是具体产品还是具体工厂可分为简单工厂模式和工厂方法模式，根据工厂的抽象程度可分为工厂方法模式和抽象工厂模式。该模式用于封装和管理对象的创建，是一种创建型模式。今天这里只讲工厂模式在Spring中是如何体现的...?

IOC控制反转也叫依赖注入，它就是典型的工厂模式，通过sessionfactory去注入实例

解释：将对象交给容器管理，你只需要在spring配置文件总配置相应的bean，以及设置相关属性，让spring容器来生成类的实例对象以及管理对象。在spring容器启动的时候，spring会把你在配置文件中配置的bean初始化好，然后在你需要调用的时候，就把它已经初始化好的那些bean分配给你需要调用这些bean的类（假设这个类名是A），分配的方法就是调用A的setter方法来注入，而不需要你在A类里面new这些bean了

?总结:对象实例化与初始化进行解耦

?单例模式

了解单例模式：https://blog.csdn.net/weixin_54361971/article/details/122280190?spm=1001.2014.3001.5501

Spring中JavaBean默认为单例，因为spring上下文中会有很多个dao\service\action对象，如果用多例模式的话，就每次要用到的时候，都会重新创建一个新的对象，内存中就会有很多重复的对象，所以单例模式的特点就是能减少我们的内存空间，节约性能。
<bean name="paramAction" class="com.zking.ioc.web.ParamAction"
		scope="singleton"></bean>
package com.zking.single.demo;

import org.junit.Test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

import com.zking.ioc.web.ParamAction;

/**
 * Spring单例多例模式的演示、区别及选择
 * 
 * @author Administrator
 *
 */
public class Demo1 {
	// scope="singleton" 默认的
	@Test
	public void test1() {
		ApplicationContext applicationContext = new ClassPathXmlApplicationContext("/spring-context.xml");
		ParamAction p1 = (ParamAction) applicationContext.getBean("paramAction");
		ParamAction p2 = (ParamAction) applicationContext.getBean("paramAction");
		System.out.println(p1 == p2);
	}
//运行结果：true

	// scope="prototype"
	@Test
	public void test2() {
		ApplicationContext applicationContext = new ClassPathXmlApplicationContext("/spring-context.xml");
		ParamAction p1 = (ParamAction) applicationContext.getBean("paramAction");
		ParamAction p2 = (ParamAction) applicationContext.getBean("paramAction");
		System.out.println(p1 == p2);
	}
//运行结果：fasle

	// 区别：单例多例的选择？
	@Test
	public void test3() {
		ApplicationContext applicationContext = new ClassPathXmlApplicationContext("/spring-context.xml");
		ParamAction p1 = (ParamAction) applicationContext.getBean("paramAction");
		ParamAction p2 = (ParamAction) applicationContext.getBean("paramAction");
		p1.execute();
		p2.execute();
	}
}
还有常用Spring中 @Repository、@Component、@Configuration @Service注解作用下的类默认都是单例模式的，所以，我目前认为在Spring下使用单例最优的方式是将类@Component注册为组件。使用场景主要有：数据库配置、Redis配置、权限配置、Filter过滤、webMvcConfig、swagger及自定义的时间转换器、类型转换器、对接第三方硬件时，调用硬件的dll、so文件等。

单独使用@Component注解，只能控制到类上，使用@Configuration+@Bean可以控制到方法级别粒度，但是尽量避免@Component+@Bean组合使用，因为@Component+@Bean并不是单例，在调用过程中可能会出现多个Bean实例，导致蜜汁错误。
并不是所有的注解默认都是单例模式，@RestController就是多例

?代理模式

了解代理模式：https://blog.csdn.net/weixin_54361971/article/details/122319616?spm=1001.2014.3001.5501

Spring中的AOP就是典型的代理模式，首先我们先聊聊AOP（面向切面编程）的的一个设计原理：

AOP可以说是对OOP的补充和完善? OOP引入了封装、继承和多态性等概念来建立一种对象层次结构，用以模拟公共行为的一个集合。当我们需要为分散的对象引入公共行为的时候，OOP则显得无能为力。也就是说，oop允许你定义从上到下的关系，但并不适合定义从左到右的关系。例如日志功能，日志代码往往水平地散布在所有对象层次中，而与它所散布到的对象的核心功能毫无关系。在OOP设计中，它导致大量代码重复，而不利于各个模块的重用。

实现AOP的技术，主要分为两大类：一是采用动态代理技术，利用截取消息的方式，对该消息进行装饰，以取代原有对象行为的执行；二是采用静态织入的方式，引入特定的语法创建“方面”，从而使得编译器可以在编译期间织入有关“方面”的代码

简单点解释，比方说你想在你的biz层所有类中都加上一个打印‘你好’的功能，这时就可以用AOP思想来做，你先写个类写个类方法，方法经实现打印‘你好’，然后IOC这个类ref="biz.* "让每个类都注入即可实现。
package com.javaxl.design.proxy.dynamic.cglib;

import org.springframework.cglib.proxy.Enhancer;
import org.springframework.cglib.proxy.MethodInterceptor;
import org.springframework.cglib.proxy.MethodProxy;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.text.SimpleDateFormat;
import java.util.Date;


class TeacherDao {
    public String teach() {
        SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
        return sdf.format(new Date()) + "：老师传授知识";
    }

    public TeacherDao sleep(int minutes) {
        System.out.println("老师睡了" + minutes + "分钟");
        return this;
    }

}

//真实代理类的外衣
class TeacherDaoProxy implements MethodInterceptor {
    private Object target;

    public TeacherDaoProxy(Object target) {
        this.target = target;
    }

    //返回一个代理对象:	是 target  对象的代理对象
    public Object getProxyInstance() {
        //1. 创建一个工具类
        Enhancer enhancer = new Enhancer();
        //2. 设置父类
        enhancer.setSuperclass(target.getClass());
        //3. 设置回调函数
        enhancer.setCallback(this);
        //4. 创建子类对象，即代理对象
        return enhancer.create();
    }

    /**
     * @param proxyIns  由CGLib动态生成的代理类实例
     * @param method    上文中实体类所调用的被代理的方法引用
     * @param args      参数值列表
     * @param methodProxy   生成的代理类对方法的代理引用
     * @return
     * @throws Throwable
     */
    @Override
    public Object intercept(Object proxyIns, Method method, Object[] args, MethodProxy methodProxy) throws Throwable {
        String methodName = method.getName();
        Object res;
        System.out.println("目标方法" + methodName + "：cglib代理开始...");
        System.out.println("真实代理对象：" + proxyIns.getClass());
        System.out.println("目标对象：" + target.getClass());
        if ("sleep".equals(methodName)) {
//                            method.invoke(target, args);
//                            obj = proxy;
            res = method.invoke(target, args);
//            res = methodProxy.invokeSuper(proxyIns,args);
            res = proxyIns;
        } else {
//                        proxy是真实代理类，method是目标方法，args是目标方法携带的参数
            res = method.invoke(target, args);
        }
        System.out.println("目标方法" + methodName + "：cglib代理结束...");
        return res;
    }
}

public class Client {
    public static void main(String[] args) {
        TeacherDao proxy = (TeacherDao) new TeacherDaoProxy(new TeacherDao()).getProxyInstance();
        proxy.sleep(111).sleep(222);
    }
}

模板模式

定义：模板方法模式在一个方法中定义一个算法骨架，并将某些步骤推迟到子类中实现。模板方法模式可以让子类在不改变算法整体结构的情况下，重新定义算法中的某些步骤

目的：1.使用模版方法模式的目的是避免编写重复代码，以便开发人员可以专注于核心业务逻辑的实现

? 2.解决接口与接口实现类之间继承矛盾问题

以上定义来自《设计模式之美》

模板模式IOC容器初始化的时候就有所应用，我们可以看一下 AbstractApplicationContext 中的 refresh 方法，它就是一个模板方法，里面调用了一系列方法，有以实现的具体方法，有未实现的抽象方法，也有空的钩子方法。这里解释一下何为钩子方法，所谓钩子方法，就是在模板方法模式的抽象类中，我们可以定义一个方法，它默认不做任何事，子类可以视情况来决定是否重写它，该方法则被成为钩子方法。
public void refresh() throws BeansException, IllegalStateException {
   synchronized (this.startupShutdownMonitor) {
      prepareRefresh();
       //此方法内部调用了两个抽象方法refreshBeanFactory()和getBeanFactory()
       //具体要取哪种beanFactory的控制权交给了子类
      ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
      prepareBeanFactory(beanFactory);
      try {
          //钩子方法
         postProcessBeanFactory(beanFactory);
         invokeBeanFactoryPostProcessors(beanFactory);
         registerBeanPostProcessors(beanFactory);
         initMessageSource();
         initApplicationEventMulticaster();
          //钩子方法
         onRefresh();
         registerListeners();
         finishBeanFactoryInitialization(beanFactory);
         finishRefresh();
      }
      catch (BeansException ex) {
         if (logger.isWarnEnabled()) {
            logger.warn("Exception encountered during context initialization - " +
                  "cancelling refresh attempt: " + ex);
         }
         destroyBeans();
         cancelRefresh(ex);
         throw ex;
      }
      finally {
         resetCommonCaches();
      }
   }
}
钩子函数应用场景：
public abstract class CodeAbstractClass {
    public void template() {   
     long start = System.currentTimeMillis();   
     if (callback())
         method();        
      long end = System.currentTimeMillis();       
       System.out.println("当前方法执行时长：" + (end - start));  
  }   

 public abstract void method();   

 public boolean callback() {     
   return true;    

    }
}
从上面可以看出：template方法默认是用作统计method方法的执行时长，但是有的时候我们无需统计代码时长，template函数中有一些其它逻辑要执行，在这里我们可以考虑采用钩子函数；钩子函数被子类覆写，覆写成false，那么method方法就不会被调用，不再统计代码时长了；前端框架Vue的生命周期就有多处用到钩子函数；

注意事项和细节

钩子函数在模板方法模式的父类中，我们可以定义一个方法，它默认不做任何事，子类可以视情况要不要覆盖它，该方法称为“钩子”

算法只存在于一个地方，也就是在父类中，容易修改。需要修改算法时，只要修改父类的模板方法或者已经实现的某些步骤，子类就会继承这些修改

一般模板方法都加上 final 关键字，防止子类重写模板方法

观察者模式

定义对象键一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知被制动更新

例如：

报社的业务就是出版报纸。
向某家报社订阅报纸，只要他们有新报纸出版，就会给你送来。只要你是他们的订户、你就会一直收到新报纸。
当你不想再看报纸的时候，取消订阅，他们就不会再送新报纸来。
只要报社还在运营，就会一直有人（或单位)向他们订阅报纸或取消订阅报纸。

报社：被观察者
订户：观察者
一个报社对应多个订户
了解观察者模式：https://blog.csdn.net/Jieur/article/details/122352165?spm=1001.2014.3001.5501

在Spring中有一个ApplicationListener，采用观察者模式来处理的，ApplicationEventMulticaster作为主题，里面有添加，删除，通知等。

spring有一些内置的事件，当完成某种操作时会发出某些事件动作，他的处理方式也就上面的这种模式，当然这里面还有很多，可以了解下spring的启动过程。
import java.util.EventListener;

/**
 * Interface to be implemented by application event listeners.
 * Based on the standard {@code java.util.EventListener} interface
 *  for the Observer design pattern. // 这里也已经说明是采用观察者模式
 *
 * <p>As of Spring 3.0, an ApplicationListener can generically declare the event type
 * that it is interested in. When registered with a Spring ApplicationContext, events
 * will be filtered accordingly, with the listener getting invoked for matching event
 * objects only.
 *
 * @author Rod Johnson
 * @author Juergen Hoeller
 * @param <E> the specific ApplicationEvent subclass to listen to
 * @see org.springframework.context.event.ApplicationEventMulticaster //主题
 */
@FunctionalInterface
public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {

	/**
	 * Handle an application event.
	 * @param event the event to respond to
	 */
	void onApplicationEvent(E event);

}
在java.util 包下除了常用的集合和map之外还有一个Observable类，他的实现方式其实就是观察者模式。里面也有添加、删除、通知等方法。

适配器模式

定义：将一个类的接口转接成用户所期待的。一个适配使得因接口不兼容而不能在一起工作的类能在一起工作，做法是将类自己的接口包裹在一个已存在的类中

例子：以手机充电为例，电压220V，手机支持5.5V，充电器相当于适配器
package com.javaxl.design.adapter.after;

/**
 * @author 代码世界里的小李
 * @site www.javaxl.com
 * @company
 * @create? 2022-01-10 15:51
 *
 * 220V的电压
 */
public class Voltage220V {
    private double voltage;

    public Voltage220V() {
        this.voltage = 220;
    }

    public double getVoltage() {
        return voltage;
    }

    public void setVoltage(double voltage) {
        this.voltage = voltage;
    }
}

/**
 * 目标接口
 */
interface Voltage5V{
    double getVoltage();
}

/**
 * 适配器：里面封装了source源到destination目标的过程
 */
class VoltageAdapter implements  Voltage5V{
    private Voltage220V voltage220V;

    public VoltageAdapter(Voltage220V voltage220V) {
        this.voltage220V = voltage220V;
    }

    @Override
    public double getVoltage() {
        return voltage220V.getVoltage() / 40;
    }
}


package com.javaxl.design.adapter.after;


public class Phone {
//    充电
    public void charge(Voltage5V voltage5V){
        double voltage = voltage5V.getVoltage();
        System.out.println("最终手机充电所用电压：" + voltage + "V");
    }
}


public class Client {
    public static void main(String[] args) {
        Phone phone = new Phone();
//        已知有一个220V的电源，要用它给手机进行充电，我们只能将220V的电源进行处理后才能给手机充上电
//        VoltageAdapter适配器对Voltage220V这个不能直接使用的电源适配后就可以使用了
        phone.charge(new VoltageAdapter(new Voltage220V()));
    }
}
AOP和MVC中，都有用到适配器模式。

spring aop框架对BeforeAdvice、AfterAdvice、ThrowsAdvice三种通知类型的支持实际上是借助适配器模式来实现的，这样的好处是使得框架允许用户向框架中加入自己想要支持的任何一种通知类型，上述三种通知类型是spring aop框架定义的，它们是aop联盟定义的Advice的子类型。

Spring中的AOP中AdvisorAdapter类，它有三个实现：MethodBeforAdviceAdapter、AfterReturnningAdviceAdapter、ThrowsAdviceAdapter。

顶层接口AdviceAdapter的源代码：
public interface AdvisorAdapter {
    boolean supportsAdvice(Advice var1);

    MethodInterceptor getInterceptor(Advisor var1);
}
MethodBeforAdviceAdapter：
public class MethodBeforeAdviceInterceptor implements MethodInterceptor, BeforeAdvice, Serializable {
    private final MethodBeforeAdvice advice;

    public MethodBeforeAdviceInterceptor(MethodBeforeAdvice advice) {
        Assert.notNull(advice, "Advice must not be null");
        this.advice = advice;
    }

    public Object invoke(MethodInvocation mi) throws Throwable {
        this.advice.before(mi.getMethod(), mi.getArguments(), mi.getThis());
        return mi.proceed();
    }
}
其他两个类就不看了。Spring会根据不同的AOP配置来使用对应的“Advice”，与策略模式不同的是，一个方法可以同时拥有多个“Advice”。

适配器模式的优缺点

　　优点：

能提高类的透明性和复用性，现有的类会被复用但不需要改变。
目标类和适配器类解耦，可以提高程序的扩展性。
在很多业务场景中符合开闭原则。

　　缺点：

在适配器代码编写过程中需要进行全面考虑，可能会增加系统复杂度。
增加代码阅读难度，过多使用适配器会使系统代码变得凌乱。

springmvc中对handler的处理使用了适配器模式。

springmvc通过HandlerMapping获取到可以处理的handler，这些handler的类型各不相同，对请求的预处理，参数获取都不相同，最简单的做法是根据不同的handler类型，做一个分支处理，不同的handler编写不同的代码。

这样的问题是很明显的，分支判断复杂，代码庞大，不符合单一职责原则。如果要增加一种handler类型，需要修改代码增加分支处理，违反了开闭原则。DispatcherServelt与多个handler发生了交互，违反迪米特法则。

而使用适配器模式，就可以很好的解决这个问题：

不直接对handler进行处理，而是将handler交给适配器HandlerAdapter去处理，这样DispatcherServlet交互的类就只剩下一个接口，HandlerAdapter，符合迪米特法则，尽可能少的与其他类发生交互；

将handler交给HandlerAdapter处理后，不同类型的handler被对应类型的HandlerAdapter处理，每个HandlerAdapter都只完成单一的handler处理，符合单一职责原则；

如果需要新增一个类型的handler，只需要新增对应类型的HandlerAdapter就可以处理，无需修改原有代码，符合开闭原则。

这样，不同的handler的不同处理方式，就在HandlerAdapter中得到了适配，对于DispatcherServlet来将，只需要统一的调用HandlerAdapter的handle()方法就可以了，无需关注不同handler的处理细节。