接上一篇讲下spring-ioc中的设计模式。Spring作为一款及其优秀的框架,其代码的编写非常优秀,里面采用了大量的设计模式。下面我们一点点分析。
先简单说下常见的设计模式
- 1、工厂模式
- 2、单例模式
- 3、策略模式
- 4、装饰器模式
参考:设计模式学习
【参考】:工厂模式的区别
工厂模式可将Java对象的调用者从被调用者的实现逻辑中分离出来,调用者只需关心被调用者必须满足的规则(接口),而不必关心实例的具体实现过程。工厂模式由抽象产品(接口)、具体产品(实现类)、生产者(工厂类)三种角色组成。
Spring中在各种BeanFactory以及ApplicationContext创建中都用到了典型的工厂方法模式。ApplicationContext的设计图如下,SpringBean的体系结构比较复杂,顶级接口是BeanFactory;BeanFactory共有三个子接口:ListableBeanFactory、HierarchicalBeanFactory和AutowireCapableBeanFactory,还有一个SimpleJndiBeanFactory实现类。这三个子接口集成了顶级接口并对BeanFactory的功能进行了增强,称为二级接口;ConfigurableBeanFactory对二级接口HierarchicalBeanFactory进行了再次增强,它还继承了另一个外来的接口SingletonBeanRegistry,可以被称为三级接口;ConfigurableListableBeanFactory是一个更强大的接口,继承了上述的所有接口,称为四级接口。其余的为抽象类,实现了Spring Bean四级接口所定义的所有功能。
【参考】: 单例
单例模式具有以下特点:
- 1、单例类只能有一个实例。
- 2、单例类必须自己创建自己的唯一实例。
- 3、单例类必须给所有其他对象提供这一实例
在Spring中,所有的bean默认都是单例创建的。在创建bean的代码中我们经常看到Singleton这个单词。下面我们通过代码看看单例是怎么实现的。
【AbstractBeanFactory】
protected T doGetBean(final String name, @Nullable final Class requiredType,
@Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
·············
//实例化依赖的bean之后可以实例化mbd本身了
//单例模式的创建
if (mbd.isSingleton()) {
sharedInstance = getSingleton(beanName, () -> {
try {
/**
*核心创建bean
*/
return createBean(beanName, mbd, args);
}
catch (BeansException ex) {
// Explicitly remove instance from singleton cache: It might have been put there
// eagerly by the creation process, to allow for circular reference resolution.
// Also remove any beans that received a temporary reference to the bean.
destroySingleton(beanName);
throw ex;
}
});
//真正的bean初始化处理
bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}
···········
}
通过将工厂函数传入getSingleton函数中,就可以获得一个Bean单例。单例的生成是通过修改createBean函数的参数实现的,其中mbd是一个RootBeanDefinition类,它存储了生成Bean实例所需要的信息。在createBean之中的代码里,程序调用实例化Bean的函数initializeBean
【参考】:策略模式
在策略模式(Strategy Pattern)中,一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。在策略模式中,我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。策略模式实际就是一堆算法族的封装。
当bean需要访问资源配置文件时,Spring有两种方式
<beans>
<bean id="test" class="com.example.Test">
<property name="tmp" value="classpath:book.xml"/>
bean>
beans>
在依赖注入的过程中,Spring会调用ApplicationContext 来获取Resource的实例。然而,Resource 接口封装了各种可能的资源类型,包括了:UrlResource,ClassPathResource,FileSystemResource等,Spring需要针对不同的资源采取不同的访问策略。在这里,Spring让ApplicationContext成为了资源访问策略的“决策者”。在资源访问策略的选择上,Spring采用了策略模式。当 Spring 应用需要进行资源访问时,它并不需要直接使用 Resource 实现类,而是调用 ApplicationContext 实例的 getResource() 方法来获得资源,ApplicationContext 将会负责选择 Resource 的实现类,也就是确定具体的资源访问策略,从而将应用程序和具体的资源访问策略分离开来。
ApplicationContext ctx = new Class PathXmlApplicationContext("bean.xml");
Resource res = ctx.getResource("book.xml");
上面的代码中,Spring 将采用和 ApplicationContext 相同的策略来访问资源。即: ApplicationContext 是 ClassPathXmlApplicationContext,则res 就是 ClassPathResource 实例。若将代码改为:
ApplicationContext ctx = new Class FileSystemXmlApplicationContext("bean.xml");
则再次调用ctx.getResource时,res 就是 ClassPathResource 实例。
【参考】:装饰器模式
通过使用修饰模式,可以在运行时扩充一个类的功能。原理是:增加一个修饰类包裹原来的类,包裹的方式一般是通过在将原来的对象作为修饰类的构造函数的参数。装饰类实现新的功能,但是,在不需要用到新功能的地方,它可以直接调用原来的类中的方法。修饰类必须和原来的类有相同的接口。
Spring中类中带有Wrapper的都是包装类,如下创建bean就是典型的装饰器模式
BeanWrapper instanceWrapper = null;
if (mbd.isSingleton()) {
instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
}
if (instanceWrapper == null) {
//根据指定的bean使用对应的侧脸创建新的实例,如工厂方法,构造函数自动注入,简单初始化
instanceWrapper = createBeanInstance(beanName, mbd, args);
}
final Object bean = (instanceWrapper != null ? instanceWrapper.getWrappedInstance() : null);
Class> beanType = (instanceWrapper != null ? instanceWrapper.getWrappedClass() : null);
mbd.resolvedTargetType = beanType;
if (beanType != null) {
// Allow post-processors to modify the merged bean definition.
synchronized (mbd.postProcessingLock) {
if (!mbd.postProcessed) {
try {
applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
}
catch (Throwable ex) {
throw new BeanCreationException(mbd.getResourceDescription(), beanName,
"Post-processing of merged bean definition failed", ex);
}
mbd.postProcessed = true;
}
}
}
当然Spring-IOC中还有很多的设计模式,比如代理,代理模式会放到AOP源码分析那里去讲解,那里才是代理模式的大量使用。