转:https://blog.csdn.net/huyang0304/article/details/82928900
接下来我们只介绍在Spring中常用的设计模式。
1.1、简单工厂模式（Factory）
应用场景：又叫做静态工厂方法（StaticFactoryMethod）模式，但不属于23种设计模式之一。简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。
Spring中的BeanFactory就是简单工厂模式的体现，根据传入一个唯一的标识来获得Bean对象，但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。
归类
特点
穷举
创建型模式
是复杂工厂模式的思维模型
批量生产、标准化
1.2、工厂方法模式（FactoryMethod）
应用场景：通常由应用程序直接使用new创建新的对象，为了将对象的创建和使用相分离，采用工厂模式,即应用程序将对象的创建及初始化职责交给工厂对象。
一般情况下,应用程序有自己的工厂对象来创建Bean.如果将应用程序自己的工厂对象交给Spring管理,那么Spring
管理的就不是普通的Bean,而是工厂Bean。
归类
特点
穷举
创建型模式
对于调用者来说，隐藏了复杂的逻辑处理过程，调用者只关心执行结果。
对于工厂来说要对结果负责，保证生产出符合规范的产品。
流水线生产
1.3、单例模式（Singleton）
应用场景：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
Spring中的单例模式完成了后半句话，即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例，这是因为Spring管理的是是任意的Java对象。Spring下默认的Bean均为单例。
归类
特点
穷举
创建型模式
保证从系统启动到系统终止，全过程只会产生一个实例。
当我们在应用中遇到功能性冲突的时候，需要使用单例模式。
配置文件、日历、OC容器
常用单例模式写法：饿汉式、懒汉式、注册式、序列化。
1.4、原型模式（Prototype）
应用场景：原型模式就是从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节。
所谓原型模式，就是Java中的克隆技术，以某个对象为原型。复制出新的对象。显然新的对象具备原型对象的特点，效率高（避免了重新执行构造过程步骤）。
归类
特点
穷举
创建型模式
首先有一个原型。
数据内容相同，但对象实例不同（完全两个个体）。
孙悟空吹毫毛
1.5、代理模式（Proxy）
应用场景：为其他对象提供一种代理以控制对这个对象的访问。从结构上来看和Decorator模式类似，但Proxy是控制，更像是一种对功能的限制，而Decorator是增加职责。
Spring的Proxy模式在AOP中有体现，比如JdkDynamicAopProxy和Cglib2AopProxy。
归类
特点
穷举
结构型模式
执行者、被代理人
对于被代理人来说，这件事情是一定要做的，但是我自己又不想做或者没有时间做。
对于代理人而言，需要获取到被代理的人个人资料，只是参与整个过程的某个或几个环节。
租房中介、售票黄牛、婚介、经纪人、快递、事务代理、非侵入式日志监听
1.6、策略模式（Strategy）
应用场景：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独
立于使用它的客户而变化。
Spring中在实例化对象的时候用到Strategy模式，在SimpleInstantiationStrategy有使用。
归类
特点
穷举
行为型模式
最终执行结果是固定的。
执行过程和执行逻辑不一样。
旅游出行方式
1.7、模板方法模式（TemplateMethod）
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。TemplateMethod使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
TemplateMethod模式一般是需要继承的。这里想要探讨另一种对TemplateMethod的理解。Spring中的JdbcTemplate，在用这个类时并不想去继承这个类，因为这个类的方法太多，但是我们还是想用到JdbcTemplate
已有的稳定的、公用的数据库连接，那么我们怎么办呢？我们可以把变化的东西抽出来作为一个参数传入JdbcTemplate的方法中。但是变化的东西是一段代码，而且这段代码会用到JdbcTemplate中的变量。怎么办？那我们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法，我们去实现这个方法，就把变化的东西集中到这里了。然后我们再传入这个回调对象到JdbcTemplate，从而完成了调用。这就是TemplateMethod不需要继承的另一种实现方式。
归类
特点
穷举
行为型模式
执行流程固定，但中间有些步骤有细微差别（运行时才确定）。
可实现批量生产。
SpringORM数据模型
1.8、委派模式（Delegate）
应用场景：不属于23种设计模式之一，是面向对象设计模式中常用的一种模式。这种模式的原理为类B和类A是两个互相没有任何关系的类，B具有和A一模一样的方法和属性；并且调用B中的方法，属性就是调用A中同名的方法和属性。B好像就是一个受A授权委托的中介。第三方的代码不需要知道A的存在，也不需要和A发生直接的联系，通过B就可以直接使用A的功能，这样既能够使用到A的各种功能，又能够很好的将A保护起来了，一举两得。
归类
特点
穷举
行为型模式
要和代理模式区分开来。
持有被委托人的引用。
不关心过程，只关心结果。
经理派发工作任务、Dispatcher
1.9、适配器模式（Adapter）
SpringAOP模块对BeforeAdvice、AfterAdvice、ThrowsAdvice三种通知类型的支持实际上是借助适配器模式来实现的，这样的好处是使得框架允许用户向框架中加入自己想要支持的任何一种通知类型，上述三种通知类型是SpringAOP模块定义的，它们是AOP联盟定义的Advice的子类型。
归类
特点
穷举
结构型模式
注重兼容、转换。
适配者与被适配这之间没有层级关系，也没有必然联系。
满足has-a的关系。
编码解码、一拖三充电头、HDMI转VGA、Type-C转USB
1.10、装饰器模式（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。基本上都是动态地给一个对象添加一些额外的职责。
归类
特点
穷举
结构型模式
1、注重覆盖、扩展。
2、装饰器和被装饰器都实现同一个接口，主要目的是为了扩展之后依旧保留OOP关系（同宗同源）。
3、满足is-a的关系。
IO流包装、数据源包装、简历包装
1.11、观察者模式（Observer）
应用场景：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象
都得到通知并被自动更新。
Spring中Observer模式常用的地方是Listener的实现。如ApplicationListener。
————————————————
版权声明：本文为CSDN博主「yyyyyhu」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/huyang0304/article/details/82928900