spring框架中用到了哪些设计模式？

如题所述

其他回答

第1个回答 2024-09-05

spring中用到哪些设计模式

1.工厂模式，这个很明显，在各种BeanFactory以及ApplicationContext创建中都用到了；

2.模版模式，这个也很明显，在各种BeanFactory以及ApplicationContext实现中也都用到了；

3.代理模式，在Aop实现中用到了JDK的动态代理；

4.单例模式，这个比如在创建bean的时候。

5.Tomcat中有很多场景都使用到了外观模式，因为Tomcat中有很多不同的组件，每个组件需要相互通信，但又不能将自己内部数据过多地暴露给其他组件。用外观模式隔离数据是个很好的方法。

6.策略模式在Java中的应用，这个太明显了，因为Comparator这个接口简直就是为策略模式而生的。Comparable和Comparator的区别一文中，详细讲了Comparator的使用。比方说Collections里面有一个sort方法，因为集合里面的元素有可能是复合对象，复合对象并不像基本数据类型，可以根据大小排序，复合对象怎么排序呢？基于这个问题考虑，Java要求如果定义的复合对象要有排序的功能，就自行实现Comparable接口或Comparator接口.

7.原型模式：使用原型模式创建对象比直接new一个对象在性能上好得多，因为Object类的clone()方法是一个native方法，它直接操作内存中的二进制流，特别是复制大对象时，性能的差别非常明显。

8.迭代器模式：Iterable接口和Iterator接口这两个都是迭代相关的接口，可以这么认为，实现了Iterable接口，则表示某个对象是可被迭代的；Iterator接口相当于是一个迭代器，实现了Iterator接口，等于具体定义了这个可被迭代的对象时如何进行迭代的

设计模式-Spring中常用的设计模式

设计模式是一种思想，是一种更快更好更优雅地解决问题的一种思想。这种思想在很多优秀的框架中都有落地。比如Spring框架。

接下来，我将从我的角度出发，粗浅的想一下，Spring框架中常用的一些设计模式。

Spring框架核心解决的问题是什么呢？个人理解是为了解决对象之间复杂的依赖关系，降低耦合。或者可以这么说，做项目我们也可以什么框架都不用，实现功能的时候，创建多个类，自己去维护类什么时候创建、使用、销毁等生命周期以及类之间的关系。自己维护的很好或者功能很简单的话，也可以不使用框架。框架本身也就是一个黑盒工具而已，开源使我们可以将其白盒化。

既然Spring框架的核心内容假设是解决对象之间复杂的依赖关系。通俗来说便是“要啥给啥”。为了实现这个目的，Spring核心的IOC容器出现了，对象都放在这个容器里，需要的时候从里面取。那就涉及到几点：

1.创建对象，保存对象，保存对象之间的关联关系

2.获取对象

涉及到如何创建，是只创建一次还是创建多次，有关联关系，先创建A还是先创建B等。单例模式、原型模式、工厂模式、策略模式可以来帮忙。

工厂模式：

Spring中的BeanFactory、FactoryBean

单例模式：

保证一个类仅有一个实例，并提供一个全局访问点。Spring下默认创建的Bean都是单例对象。

常用的单例模式写法又有很多：最简单的就是懒汉式了，还有饿汉式、注册式、序列化方式、枚举方式等。

原型模式：

Java中的克隆对象。以某个对象为原型，复制出一个新的对象。两个对象内容相同，但是对象实例不同。

用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。

策略模式：

一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。

在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的context对象。策略对象改变context对象的执行算法。

定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换。

获取对象的时候，有策略方法，也可以通过代理进行功能增强等。策略模式、代理模式、模板方法模式、适配器模式、装饰器模式等

代理模式：

为其他对象提供一种代理以控制对这个对象的访问。从结构上来看和装饰器模式类似，但Proxy是控制，更像是一种对功能的限制，而装饰器是增加职责。

Spring的AOP代理，应该是很出名的。JdkDynamicAopProxy、Cglib2AopProxy。

模板模式：

定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。比如JdbcTemplate

适配器模式：

将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

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

属于结构型模式，适配类与被适配类之间没有必然联系。满足has-a关系。

装饰器模式：

属于结构型模式。满足is-a关系。

Spring中用到的包装器模式在类名上有两种表现：一种是类名中含有Wrapper，另一种是类名中含有Decorator。基本上都是动态地给一个对象添加一些额外的职责。

观察者模式：

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

当对象间存在一对多关系时，则使用观察者模式（ObserverPattern）。比如，当一个对象被修改时，则会自动通知依赖它的对象。观察者模式属于行为型模式。

Spring中Observer模式常用的地方是Listener的实现。如ApplicationListener。

spring主要运用那些设计模式，单例模式是怎么实现的？

设计模式作为工作学习中的枕边书，却时常处于勤说不用的尴尬境地，也不是我们时常忘记，只是一直没有记忆。

今天，螃蟹在IT学习者网站就设计模式的内在价值做一番探讨，并以spring为例进行讲解，只有领略了其设计的思想理念，才能在工作学习中运用到“无形”。

Spring作为业界的经典框架，无论是在架构设计方面，还是在代码编写方面，都堪称行内典范。好了，话不多说，开始今天的内容。

spring中常用的设计模式达到九种，我们举例说明：

第一种：简单工厂

又叫做静态工厂方法（StaticFactoryMethod）模式，但不属于23种GOF设计模式之一。

简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。

spring中的BeanFactory就是简单工厂模式的体现，根据传入一个唯一的标识来获得bean对象，但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。如下配置，就是在HelloItxxz类中创建一个itxxzBean。

beans

beanid="singletonBean"class="com.itxxz.HelloItxxz"

constructor-arg

valueHello!这是singletonBean!value

/constructor-arg

/bean

beanid="itxxzBean"class="com.itxxz.HelloItxxz"

singleton="false"

constructor-arg

valueHello!这是itxxzBean!value

/constructor-arg

/bean

/beans

第二种：工厂方法（FactoryMethod）

通常由应用程序直接使用new创建新的对象，为了将对象的创建和使用相分离，采用工厂模式,即应用程序将对象的创建及初始化职责交给工厂对象。

一般情况下,应用程序有自己的工厂对象来创建bean.如果将应用程序自己的工厂对象交给Spring管理,那么Spring管理的就不是普通的bean,而是工厂Bean。

螃蟹就以工厂方法中的静态方法为例讲解一下：

importjava.util.Random;

publicclassStaticFactoryBean{

publicstaticIntegercreateRandom(){

returnnewInteger(newRandom().nextInt());

}

建一个config.xm配置文件，将其纳入Spring容器来管理,需要通过factory-method指定静态方法名称

beanid="random"

class="example.chapter3.StaticFactoryBean"factory-method="createRandom"//createRandom方法必须是static的,才能找到scope="prototype"

测试:

publicstaticvoidmain(String[]args){

//调用getBean()时,返回随机数.如果没有指定factory-method,会返回StaticFactoryBean的实例,即返回工厂Bean的实例???XmlBeanFactoryfactory=newXmlBeanFactory(newClassPathResource("config.xml"));???System.out.println("我是IT学习者创建的实例:"+factory.getBean("random").toString());

}

第三种：单例模式（Singleton）

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

spring中的单例模式完成了后半句话，即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例，这是因为spring管理的是是任意的java对象。

核心提示点：Spring下默认的bean均为singleton，可以通过singleton=“true|false”或者scope=“？”来指定

第四种：适配器（Adapter）

在Spring的Aop中，使用的Advice（通知）来增强被代理类的功能。Spring实现这一AOP功能的原理就使用代理模式（1、JDK动态代理。2、CGLib字节码生成技术代理。）对类进行方法级别的切面增强，即，生成被代理类的代理类，并在代理类的方法前，设置拦截器，通过执行拦截器重的内容增强了代理方法的功能，实现的面向切面编程。

Adapter类接口：Target

publicinterfaceAdvisorAdapter{

booleansupportsAdvice(Adviceadvice);

MethodInterceptorgetInterceptor(Advisoradvisor);

}MethodBeforeAdviceAdapter类，Adapter

classMethodBeforeAdviceAdapterimplementsAdvisorAdapter,Serializable{

publicbooleansupportsAdvice(Adviceadvice){

return(adviceinstanceofMethodBeforeAdvice);

}

publicMethodInterceptorgetInterceptor(Advisoradvisor){

MethodBeforeAdviceadvice=(MethodBeforeAdvice)advisor.getAdvice();

returnnewMethodBeforeAdviceInterceptor(advice);

}

第五种：包装器（Decorator）

在我们的项目中遇到这样一个问题：我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。我们以往在spring和hibernate框架中总是配置一个数据源，因而sessionFactory的dataSource属性总是指向这个数据源并且恒定不变，所有DAO在使用sessionFactory的时候都是通过这个数据源访问数据库。但是现在，由于项目的需要，我们的DAO在访问sessionFactory的时候都不得不在多个数据源中不断切换，问题就出现了：如何让sessionFactory在执行数据持久化的时候，根据客户的需求能够动态切换不同的数据源？我们能不能在spring的框架下通过少量修改得到解决？是否有什么设计模式可以利用呢？

首先想到在spring的applicationContext中配置所有的dataSource。这些dataSource可能是各种不同类型的，比如不同的数据库：Oracle、SQLServer、MySQL等，也可能是不同的数据源：比如apache提供的org.apache.commons.dbcp.BasicDataSource、spring提供的org.springframework.jndi.JndiObjectFactoryBean等。然后sessionFactory根据客户的每次请求，将dataSource属性设置成不同的数据源，以到达切换数据源的目的。

spring中用到的包装器模式在类名上有两种表现：一种是类名中含有Wrapper，另一种是类名中含有Decorator。基本上都是动态地给一个对象添加一些额外的职责。

第六种：代理（Proxy）

为其他对象提供一种代理以控制对这个对象的访问。?从结构上来看和Decorator模式类似，但Proxy是控制，更像是一种对功能的限制，而Decorator是增加职责。

spring的Proxy模式在aop中有体现，比如JdkDynamicAopProxy和Cglib2AopProxy。

第七种：观察者（Observer）

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

spring中Observer模式常用的地方是listener的实现。如ApplicationListener。

第八种：策略（Strategy）

定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。

spring中在实例化对象的时候用到Strategy模式

在SimpleInstantiationStrategy中有如下代码说明了策略模式的使用情况：

第九种：模板方法（TemplateMethod）

定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。TemplateMethod使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

TemplateMethod模式一般是需要继承的。这里想要探讨另一种对TemplateMethod的理解。spring中的JdbcTemplate，在用这个类时并不想去继承这个类，因为这个类的方法太多，但是我们还是想用到JdbcTemplate已有的稳定的、公用的数据库连接，那么我们怎么办呢？我们可以把变化的东西抽出来作为一个参数传入JdbcTemplate的方法中。但是变化的东西是一段代码，而且这段代码会用到JdbcTemplate中的变量。怎么办？那我们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法，我们去实现这个方法，就把变化的东西集中到这里了。然后我们再传入这个回调对象到JdbcTemplate，从而完成了调用。这可能是TemplateMethod不需要继承的另一种实现方式吧。

spring中使用了哪些设计模式

这个太多了，spring不断发展的子项目里面更是用到了很多巧妙的设计模式。在这里最主要的AOP,和IOC分别运用了动态代理和工厂模式。

spring中使用了哪些经典设计模式，举例说明

developerWorks中国

技术主题

Javatechnology

文档库

Spring框架的设计理念与设计模式分析

Spring作为现在最优秀的框架之一，已被广泛的使用，并且有很多对其分析的文章。本文将从另外一个视角试图剖析出Spring框架的作者设计Spring框架的骨骼架构的设计理念，有那几个核心组件？为什么需要这些组件？它们又是如何结合在一起构成Spring的骨骼架构？Spring的AOP特性又是如何利用这些基础的骨骼架构来工作的？Spring中又使用了那些设计模式来完成它的这种设计的？它的这种设计理念对对我们以后的软件设计有何启示？本文将详细解答这些问题。

20评论：

许令波,Java开发工程师,淘宝网

2010年6月10日

内容

在IBMBluemix云平台上开发并部署您的下一个应用。

现在就开始免费试用

Spring的骨骼架构

Spring总共有十几个组件，但是真正核心的组件只有几个，下面是Spring框架的总体架构图：

图1.Spring框架的总体架构图

从上图中可以看出Spring框架中的核心组件只有三个：Core、Context和Beans。它们构建起了整个Spring的骨骼架构。没有它们就不可能有AOP、Web等上层的特性功能。下面也将主要从这三个组件入手分析Spring。

Spring的设计理念

前面介绍了Spring的三个核心组件，如果再在它们三个中选出核心的话，那就非Beans组件莫属了，为何这样说，其实Spring就是面向Bean的编程（BOP,BeanOrientedProgramming），Bean在Spring中才是真正的主角。

Bean在Spring中作用就像Object对OOP的意义一样，没有对象的概念就像没有面向对象编程，Spring中没有Bean也就没有Spring存在的意义。就像一次演出舞台都准备好了但是却没有演员一样。为什么要Bean这种角色Bean或者为何在Spring如此重要，这由Spring框架的设计目标决定，Spring为何如此流行，我们用Spring的原因是什么，想想你会发现原来Spring解决了一个非常关键的问题他可以让你把对象之间的依赖关系转而用配置文件来管理，也就是他的依赖注入机制。而这个注入关系在一个叫Ioc容器中管理，那Ioc容器中有又是什么就是被Bean包裹的对象。Spring正是通过把对象包装在Bean中而达到对这些对象管理以及一些列额外操作的目的。

它这种设计策略完全类似于Java实现OOP的设计理念，当然了Java本身的设计要比Spring复杂太多太多，但是都是构建一个数据结构，然后根据这个数据结构设计他的生存环境，并让它在这个环境中按照一定的规律在不停的运动，在它们的不停运动中设计一系列与环境或者与其他个体完成信息交换。这样想来回过头想想我们用到的其他框架都是大慨类似的设计理念。

核心组件如何协同工作

前面说Bean是Spring中关键因素，那Context和Core又有何作用呢？前面吧Bean比作一场演出中的演员的话，那Context就是这场演出的舞台背景，而Core应该就是演出的道具了。只有他们在一起才能具备能演出一场好戏的最基本的条件。当然有最基本的条件还不能使这场演出脱颖而出，还要他表演的节目足够的精彩，这些节目就是Spring能提供的特色功能了。

我们知道Bean包装的是Object，而Object必然有数据，如何给这些数据提供生存环境就是Context要解决的问题，对Context来说他就是要发现每个Bean之间的关系，为它们建立这种关系并且要维护好这种关系。所以Context就是一个Bean关系的集合，这个关系集合又叫Ioc容器，一旦建立起这个Ioc容器后Spring就可以为你工作了。那Core组件又有什么用武之地呢？其实Core就是发现、建立和维护每个Bean之间的关系所需要的一些列的工具，从这个角度看来，Core这个组件叫Util更能让你理解。

它们之间可以用下图来表示：

图2.三个组件关系

核心组件详解

这里将详细介绍每个组件内部类的层次关系，以及它们在运行时的时序顺序。我们在使用Spring是应该注意的地方。

Bean组件

前面已经说明了Bean组件对Spring的重要性，下面看看Bean这个组件式怎么设计的。Bean组件在Spring的org.springframework.beans包下。这个包下的所有类主要解决了三件事：Bean的定义、Bean的创建以及对Bean的解析。对Spring的使用者来说唯一需要关心的就是Bean的创建，其他两个由Spring在内部帮你完成了，对你来说是透明的。

SpringBean的创建时典型的工厂模式，他的顶级接口是BeanFactory，下图是这个工厂的继承层次关系：

图4.Bean工厂的继承关系

BeanFactory有三个子类：ListableBeanFactory、HierarchicalBeanFactory和AutowireCapableBeanFactory。但是从上图中我们可以发现最终的默认实现类是DefaultListableBeanFactory，他实现了所有的接口。那为何要定义这么多层次的接口呢？查阅这些接口的源码和说明发现，每个接口都有他使用的场合，它主要是为了区分在Spring内部在操作过程中对象的传递和转化过程中，对对象的数据访问所做的限制。例如ListableBeanFactory接口表示这些Bean是可列表的，而HierarchicalBeanFa