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

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

        如下配置，就是在 HelloItxxz 类中创建一个 itxxzBean。

Java代码  

1. <beans>  

2.     <bean id="singletonBean" class="com.itxxz.HelloItxxz">  

3.         <constructor-arg>  

4.             <value>Hello! 这是singletonBean!value>  

5.         </constructor-arg>  

6.    </ bean>  

7.  

8.     <bean id="itxxzBean" class="com.itxxz.HelloItxxz"  

9.         singleton="false">  

10.         <constructor-arg>  

11.             <value>Hello! 这是itxxzBean! value>  

12.         </constructor-arg>  

13.     </bean>  

14. </beans>  

2. 工厂方法（Factory Method）

        定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。

        Spring中的FactoryBean就是典型的工厂方法模式。如下图：

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

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

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

Java代码   

1. import java.util.Random;  

2. public class StaticFactoryBean {  

3.       public static Integer createRandom() {  

4.            return new Integer(new Random().nextInt());  

5.        }  

6. }  

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

Xml代码  

1. <bean id="random"  

2. class="example.chapter3.StaticFactoryBean"  

3. factory-method="createRandom" //createRandom方法必须是static的,才能找到  

4. scope="prototype"  

5. />  

        测试:

Java代码  

1. public static void main(String[] args) {  

2.   

3.       //调用getBean()时,返回随机数.如果没有指定factory-method,会返回StaticFactoryBean的实例,即返回工厂Bean的实例  

4.       XmlBeanFactory factory = new XmlBeanFactory(new ClassPathResource("config.xml"));  

5.       System.out.println("我是IT学习者创建的实例:"+factory.getBean("random").toString());  

6. }  

装饰器模式：BeanWrapper

   动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。

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

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

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

代理模式：AopProxy

 为其他对象提供一种代理以控制对这个对象的访问。

        从结构上来看和Decorator模式类似，但Proxy是控制，更像是一种对功能的限制，而Decorator是增加职责。

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

单例模式：ApplicationContext

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

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

/**
     * 单例对象的缓存
     */ private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);  protected Object getSingleton(String beanName, boolean allowEarlyReference) { //首先通过名字查找这个单例bean存在不存在   Object  singletonObject = this.singletonObjects.get(beanName);  if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {  synchronized (this.singletonObjects) {  //查看缓存中是否存在这个bean实例  singletonObject = this.earlySingletonObjects.get(beanName); //如果这个时候的bean实例还是为空并且允许懒加载 if (singletonObject == null && allowEarlyReference) { ObjectFactory<?> singletonFactory= this.singletonFactories.get(beanName); if (singletonFactory != null) {
                               singletonObject = singletonFactory.getObject(); this.earlySingletonObjects.put(beanName, singletonObject); this.singletonFactories.remove(beanName);
                            }
                        }
                    }
                } return singletonObject;
            }

其实getBean（）这个方法不仅仅和单例相关，还和prototype相关，毕竟只是获取Bean,Bean的scope也可能为prototype，有兴趣可以调试一下Spring创建bean的过程。后续代码省略。。。。。。

委派模式：DispatcherServlet

   在spring中的体现：Spring MVC框架中的DispatcherServlet其实就用到了委派模式。

委派模式的作用：基本作用就是负责任务的调用和分配任务，跟代理模式很像，可以看做是一种特殊情况下的静态代理的全权代理，但是代理模式注重过程，而委派模式注重结果

策略模式: HandlerMapping

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

适配器模式：HandlerApdapter

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

       Spring中在对于AOP的处理中有Adapter模式的例子，见如下图：

        由于Advisor链需要的是MethodInterceptor对象，所以每一个Advisor中的Advice都要适配成对应的MethodInterceptor对象。

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

        Adapter类接口：Target

Java代码  

1. public interface AdvisorAdapter {  

2.     boolean supportsAdvice(Advice advice);  

3.     MethodInterceptor getInterceptor(Advisor advisor);  

4. }  

        MethodBeforeAdviceAdapter类，Adapter

Java代码  

1. class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {  

2.    

3.       public boolean supportsAdvice(Advice advice) {  

4.             return (advice instanceof MethodBeforeAdvice);  

5.       }  

6.    

7.       public MethodInterceptor getInterceptor(Advisor advisor) {  

8.             MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();  

9.       return new MethodBeforeAdviceInterceptor(advice);  

10.       }  

11. }  

 动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。

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

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

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

模板方法模式：JdbcTemplate

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

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

        类图：

以下是一个具体的例子：

        JdbcTemplate中的execute方法：

        JdbcTemplate执行execute方法：

观察者模式：ContextLoaderListener

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

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

二、Spring 的四大模块及典型的设计模式

1、Spring IOC   工厂模式、单例模式、装饰器模式

2、Spring AOP  代理模式、观察者模式

3、Spring MVC  委派模式、适配器模式

4、Spring JDBC 模板方法模式

三、Spring 中常见设计模式分类