设计模式的归纳，结合Spring用到的一些地方(学习笔记)

内容来自于以下的知识的归纳
传送门：JavaGuide && 菜鸟教程
本博客仅用来记录学习使用，如果能帮助到大家也是很开心的(❁´◡`❁)

设计模式

• 设计模式是什么？是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结，所以能避免我们在编程的时候走弯路。根据菜鸟教程上的归纳的设计模式总共23种设计模式（天呐！怎么这么多呀），分别为创建型模式、结构型模式、行为型模式三大类。
• 设计模式的六大原则：

1.开闭原则：对扩展开发，对修改关闭
2.里氏代换原则：对实现抽象化的具体步骤的规范
3.依赖倒装原则：这个原则是开闭原则的基础，针对接口编程，依赖于抽象而不是依赖于具体。
4. 接口隔离原则：使用的多个隔离的接口，比使用单个接口要好。
5. 迪米特法则：最少知道原则，一个实体应当尽量少地与其他实体之间相互作用，是的系统功能模块相对独立。
6.合成复用原则：尽量使用合成/聚合地方式，而不是继承。

创建者模式

这类设计模式提供了一种创建对象的同时隐藏创建逻辑的方式，而不是使用new运算符直接是实例化对象。这使得程序在判断对某个给定实例需要创建哪些对象是更加灵活。

工厂模式

提供一种创建对象地最佳方式，创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象

• 优点： 1、一个调用者想创建一个对象，只要知道其名称就可以了。 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现，调用者只关心产品的接口。
• 缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。

• Spring使用工厂模式可以通过BeanFactory或ApplicationContext创建bean对象。
• BeanFactory：延迟注入，相比于ApplicationContext来说会占用更少的内存，程序启动速度快更快。
• ApplicationContext：容器启动的时候，一次性创建所有bean。BeanFactory仅提供了最基本的依赖注入支持，ApplicationContext扩展了BeanFactory，除了有BeanFactory的功能还有额外更多功能，所以一般开发人员使用ApplicationContext会更多。
• ApplicationContext的三个实现类：

1. ClassPathXmlApplicationContext：把上下文文件当前类路径资源载入上下文定义信息。
2. FileSystemXmlApplicationContext：从文件系统中的XML文件载入上下文定义信息。
3. XmlWebApplicationContext：从Web系统中的XML文件载入上下文定义信息。

抽象工厂

围绕一个超级工厂创建其他工厂，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。

• 优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。
• 缺点：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。

单例模式

可以直接访问，不需要实例化该类的对象；单例类只能有一个实例，必须自己创建自己的唯一实例，必须给所有其他对象提供这一实例。

• 优点：
  1、在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。
  2、避免对资源的多重占用（比如写文件操作)
• 缺点：没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。

• Spring中的bean的默认作用域就是singleton （单例）的。

建造者模式

使用多个简单的对象一步一步构建成一个复杂的对象。

• 优点： 1、建造者独立，易扩展。 2、便于控制细节风险。
• 缺点： 1、产品必须有共同点，范围有限制。 2、如内部变化复杂，会有很多的建造类。

原型模式

用于创建重复的对象，同时又能保证性能。

• 优点： 1、性能提高。 2、逃避构造函数的约束。
• 缺点： 1、配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。 2、必须实现 Cloneable 接口。

结构型模式

适配器模式

是作为两个不兼容的接口之间的桥梁。栗子🌰：音频播放器设备只能播放 mp3 文件，通过使用一个更高级的音频播放器来播放 vlc 和 mp4 文件。

• 优点： 1、可以让任何两个没有关联的类一起运行。 2、提高了类的复用。 3、增加了类的透明度。 4、灵活性好。
• 缺点： 1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。 2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。

• SpringAOP中的 适配器模式，虽然SpringAOP是基于代理模式，但是SpringAOP的增强或通知使用到了适配器模式，与之相关的接口是AdvisorAdapter。每个类型的Advice都有对应的拦截器MethoBeforeAdviceInter、AfterReturningAdviceAdapter、AfterReturningAdviceInterceptor。Spring预定义的通知要通过对应的适配器，适配成 MethodInterceptor接口(方法拦截器)类型的对象（如：MethodBeforeAdviceInterceptor 负责适配 MethodBeforeAdvice）。
• 在SpringMvc中，DispatcherServlet根据请求信息调用HandlerMapping，解析请求对应的Handler。解析到对应的Handler(也就是我们平时说的Controller控制器)后，开始由HandlerAdapter适配器处理。HandlerAdapter作为期望接口，具体的适配器实现类用于对目标类进行适配，Controller作为需要适配的类。

桥接模式

用于把抽象化与实现化解耦，是的二者可以独立变化。

• 优点： 1、抽象和实现的分离。 2、优秀的扩展能力。 3、实现细节对客户透明。
• 缺点：桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。

过滤器模式

允许开发人员使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把他们连接起来。

组合模式

是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及真题层次。

• 优点： 1、高层模块调用简单。 2、节点自由增加。
• 缺点：在使用组合模式时，其叶子和树枝的声明都是实现类，而不是接口，违反了依赖倒置原则。

装饰器模式

允许向一个现有的对象添加新的功能，同时又不改变其结构。

• 优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。
• 缺点：多层装饰比较复杂。

外观模式

隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。

• 优点： 1、减少系统相互依赖。 2、提高灵活性。 3、提高了安全性。
• 缺点：不符合开闭原则，如果要改东西很麻烦，继承重写都不合适。

享元模式

主要用于减少创建对象的数量，以减少内存占用和提高性能。

• 优点：大大减少对象的创建，降低系统的内存，使效率提高。
• 缺点：提高了系统的复杂度，需要分离出外部状态和内部状态，而且外部状态具有固有化的性质，不应该随着内部状态的变化而变化，否则会造成系统的混乱。

代理模式

一个类代表列一个类的功能。

• 优点： 1、职责清晰。 2、高扩展性。 3、智能化。
• 缺点： 1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。 2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。

• SpirngAOP就是基于动态代理的，如果要代理的对象，实现了某个接口，那么SpringAOP会使用JDKProxy，去创建代理对象，而对于没有实现接口的对象，只能使用Cglib生成代理对象的子类来作为代理。

行为型模式

责任链模式

为请求创建一个接受者对象的链，对发送者和接收者进行解耦。

• 优点： 1、降低耦合度。它将请求的发送者和接收者解耦。 2、简化了对象。使得对象不需要知道链的结构。 3、增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。 4、增加新的请求处理类很方便。
• 缺点： 1、不能保证请求一定被接收。 2、系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。 3、可能不容易观察运行时的特征，有碍于除错。

命令行模式

是一种数据驱动的设计模式，以命令的形式包裹在对象中并传给调用对象。

• 优点： 1、降低了系统耦合度。 2、新的命令可以很容易添加到系统中去。
• 缺点：使用命令模式可能会导致某些系统有过多的具体命令类。

解释器模式

提供了评估语言的语法表达式的方法

• 优点： 1、可扩展性比较好，灵活。 2、增加了新的解释表达式的方式。 3、易于实现简单文法
• 缺点： 1、可利用场景比较少。 2、对于复杂的文法比较难维护。 3、解释器模式会引起类膨胀。 4、解释器模式采用递归调用方法。

迭代器模式

用于顺序访问集合对象的元素，不需要知道集合对象的底层表示。

• 优点： 1、它支持以不同的方式遍历一个聚合对象。 2、迭代器简化了聚合类。 3、在同一个聚合上可以有多个遍历。 4、在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。
• 缺点：由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。

中介模式

是用来降低多个对象和类之间的通信复杂性。

• 优点： 1、降低了类的复杂度，将一对多转化成了一对一。 2、各个类之间的解耦。 3、符合迪米特原则。
• 缺点：中介者会庞大，变得复杂难以维护。

备忘录模式

保存一个对象的某个状态，以便在适当的时候恢复对象，

• 优点： 1、给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。 2、实现了信息的封装，使得用户不需要关心状态的保存细节。
• 缺点：消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。

观察者模式

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

• 优点： 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。
• 缺点： 1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。

状态模式

该模式下，类的行为时基于它的状态改变的。

• 优点： 1、封装了转换规则。 2、枚举可能的状态，在枚举状态之前需要确定状态种类。 3、将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。 4、允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。 5、可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
• 缺点： 1、状态模式的使用必然会增加系统类和对象的个数。 2、状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。 3、状态模式对"开闭原则"的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。

空对象模式

该模式下，一个空对象取代NULL对象实例的检查。Null 对象不是检查空值，而是反应一个不做任何动作的关系。这样的 Null 对象也可以在数据不可用的时候提供默认的行为。在空对象模式中，我们创建一个指定各种要执行的操作的抽象类和扩展该类的实体类，还创建一个未对该类做任何实现的空对象类，该空对象类将无缝地使用在需要检查空值的地方。

策略模式

该模式中，一个类的行为或其算法可以在运行时更改。

• 优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。
• 缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。

模板方法

该模式中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。

• 优点： 1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。
• 缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。

• Spring中JdbcTemplate、hiberbateTemplate、RedisTemplate等以Template结尾的对数据库操作的类，他们就使用到了模板模式，一般情况下，我们都是使用继承的方式来实现模板模式，但是 Spring 并没有使用这种方式，而是使用Callback 模式与模板方法模式配合，既达到了代码复用的效果，同时增加了灵活性。

访问者模式

该模式中，我们使用了一个访问者类，它改变了元素类的执行方法。

• 优点： 1、符合单一职责原则。 2、优秀的扩展性。 3、灵活性。
• 缺点： 1、具体元素对访问者公布细节，违反了迪米特原则。 2、具体元素变更比较困难。 3、违反了依赖倒置原则，依赖了具体类，没有依赖抽象。