Spring框架涉及到的设计模式：
Spring用到了很多的设计模式，其中最重要的两个设计模式是：
1、 工厂模式
a) Spring容器就是实例化和管理Bean的工厂 工厂模式可以将Java对象的调用者从被调用者的实现逻辑中分离出来。调用者只关心被调用者必须满足的某种规则，这里的规则我们可以看作是接口，而不必关心实例的具体实现过程，具体的实现过程，有Bean工厂来完成。
2、 单态模式【单例模式】
a) Spring默认将所有的Bean设置成 单例模式，即对所有的相同id的Bean的请求，都将返回同一个共享的Bean实例。这样就可以大大降低Java创建对象和销毁时的系统开销。使用Spring将Bean设置称为单例行为，则无需自己完成单例模式。
回顾：单态模式【单例模式】
单态模式限制了类的实例的创建，采用这种设计模式设计的类，可以保证仅有一个实例，并提供访问该实例的全局访问点。
J2EE应用了大量的组件，都需要保证一个类只有一个实例，比如：数据块引擎的访问点只能有一个。而更多的时候，是为了提高性能。应用程序应该尽量减少Java对象的创建和销毁时的开销。那么使用单例模式可以避免Java频繁的实例化。让相同的实例全部共享同一个内存区，为了防止单态模式类的实例频繁实例化，应该将类的构造函数设置为私有的，这样只能通过静态方法获取类的实例，而静态方法则需要保证每次返回的实例都是同一个，那么就需要将该类的实例设置成类的属性，该属性需要在静态的方法里面访问，因此该属性还必须是静态的属性。说了这么多，见如下代码：
public class Person {
//私有Person类型的属性
private static Person per;
//私有构造
private Person(){}
//返回该类的实例的静态方法
public static Person CreateObject(){
if (per==null) {
per=new Person();
}
return per;
public static void main(String[] args) {
Person p_one=Person.CreateObject();
Person p_two=Person.CreateObject();
回顾：工厂模式
工厂模式：根据调用数据返回某个类的一个实例，此类可能是多个类的某一个实例，通常这些类满足共同的接口或者父类，而调用者不用关心工厂里有多少个类，它只关心生产出来的实例是否满足某种规范。这个模式提供清晰的角色划分，降低程序耦合。
在工厂模式中，接口生产的全部实例通常实现相同的接口或者继承同一个类，接口里面全部实现共同拥有的方法，但是这些方法在不同的实现类中，他们的实现方式不尽相同，程序的调用者不关心具体是如何实现的，从而降低了系统的异构代价。
见示例：
Spring的实现
前面我们回顾了单例模式和工厂模式的实现，下面我们看一下Spring是如何实现这两种模式的。
这里我们无需修改接口的实现类，也就是说无需修改接口及其实现类，但是因为Spring是用工厂模式实现的，所以我们就不用写什么工厂类了，就交给Spring来实现了。Spring通过配置文件，就可以管理所有的bean，而这些bean就是Spring工厂能产生的实例，因此，首先我们在Spring配置文件中对两个实例进行配置。
Spring核心机制
前面说到Spring的核心机制就是依赖注入，现在我们就来看看什么是依赖注入：
控制反转和依赖注入
当某个角色需要另一个角色协助的时候，在传统的程序设计过程中，通常由调用者创建被调用者的实例。但是在Spring里面，创建被调用者的工作不再由调用者来完成，因此被称为控制反转，创建被调用者实例的工作通常由Spring容器来完成，然后注入调用者，因此也称之为依赖注入。
依赖：
两个元素中一个定义发生改变则会引起另一个元素发生改变，则称这两个元素之间存在依赖关系。
一个类要发消息给另一个类，一个类将另一个类作为数据的一部分，一个类操作另一个类作为其参数。这些情况都是一个类依赖另一个类。类与类之间的依赖关系增加类程序的复杂程度，我们在开发一个类的时候，还要考虑相关的其他类的属性和行为。
早期的时候：程序只是用来计算，没有复杂的逻辑，面向过程就可以搞定类，后来程序规模越来越大，需要处理的逻辑就越来越复杂，类与类之间的关系也就越来越复杂，面向对象就有必要了，当我们用一个程序模拟一个柜子组装的过程的时候，我们把挡板，框架，钉子等柜子的组件作为不同的对象，而当我们组装的时候，主要把这些对象组合在一起就可以形成一个柜子。这里我们可以看到面向对象的优点。
软件的需求增长是没有止境的，当我们实现的系统越来越复杂，面向对象也有苍白的时候，这个时候我们就需要更多的理论和方法来解决这些问题，系统变得复杂因为系统之间的关联程度太高来了，也就是说各模块之间的依赖程度太高了，我们如果采用组件化的思想降低个系统各组件的依赖关系，实现每个组件的时候，只需要考虑这个系统所要实现的功能以及各个组件和其他部分之间的接口就可以了。
我们可以看一下我们的电脑，电脑，主板是由主板厂商生产的，CPU是CPU厂商生产的，硬盘是由硬盘厂商生产的等等，那么硬盘的厂商设计产品的时候，需不需要CPU支持什么指令集？主板采用什么样的芯片组呢？当然不需要，它只知道别人会留好接口，他也只会按照行业标准给别人留好接口就可以了。电脑的各个组件之间当然是有依赖关系的，但是由于明确定义了他们之间的接口，各组件实现的时候，完全不用考虑这些组件之间的依赖关系，从而使得我们获得了构建复杂系统的能力。组件之间的依赖关系和接口的重要性，在将各个组件组装在一起的时候得以体现。通过这中开发模式，我们还获得了一种能力，可以随意更换接口的实现。更换接口的实现，而不是接口，例如：电脑采用什么样的显示器，随你。你可以使用液晶的，也可以采用等离子显示器，只要接口不变就可以了。
Spring提倡面向接口编程，也是基于这种的考虑，所谓的依赖注入，就是当某个角色，需要另外一个角色协助的时候，在传统的程序当中，通常要实例化被调用者的实例，但是在 Spring里面呢，创建被调用者的实例的工作，有Spring容器来实现。然后Spring容器会不把被调用者的实例注入到调用者那里。依赖注入让Bean与Bean之间的关系以配置文件的形式组织在一起。而不是以编码的方式耦合在一起。
其实：不管是依赖注入还是控制反转，都采用了Spring动态，灵活的方式来管理各种对象，对象之间的具体的实现是透明的。