全文链接：https://www.cnblogs.com/nullering/p/9684820.html
设计模式深入内容较多，我这里只是列举一些考试中的概念，如果大家想深入理解一下可以参考这个大佬的博客：https://www.cnblogs.com/zuoxiaolong/category/509144.html
一：概述
概念：设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
设计模式具有“适应需求变化”的优点。
基本原则：模块应对外扩展开放，而对修改关闭，要针对接口，而不是组合，抽象不应该依赖于细节，细节应当依赖于抽象
基本分类：共23种模式 3种分类 创建型5 结构型7 行为型11
二：创建型5种 相公生原子
对象实例化的模式，创建型模式用于解耦对象的实例化过程。
抽象工厂模式（Abstract Factory Pattern）
定义：（为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类。）
所谓抽象工厂模式就是提供一个接口，用于创建相关或者依赖对象的家族，而不需要明确指定具体类。他允许客户端使用抽象的接口来创建一组相关的产品，而不需要关系实际产出的具体产品是什么。这样一来，客户就可以从具体的产品中被解耦。它的优点是隔离了具体类的生成，使得客户端不需要知道什么被创建了，而缺点就在于新增新的行为会比较麻烦，因为当添加一个新的产品对象时，需要更加需要更改接口及其下所有子类。
工厂方法模式
定义：（定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。）
工厂方法模式非常符合“开闭原则”，当需要增加一个新的产品时，我们只需要增加一个具体的产品类和与之对应的具体工厂即可，无须修改原有系统。同时在工厂方法模式中用户只需要知道生产产品的具体工厂即可，无须关系产品的创建过程，甚至连具体的产品类名称都不需要知道。虽然他很好的符合了“开闭原则”，但是由于每新增一个新产品时就需要增加两个类，这样势必会导致系统的复杂度增加。
生成器模式（Builder Pattern）
定义：（将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。）
使用场景：
原型模式（Prototype Pattern）
定义：（用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。）
单子模式 （Singleton Pattern）
定义：（确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。）
使用场景：
当系统中只需要一个实例对象或者系统中只允许一个公共访问点，除了这个公共访问点外，不能通过其他访问点访问该实例时，可以使用单例模式。
单例模式的主要优点就是节约系统资源、提高了系统效率，同时也能够严格控制客户对它的访问。也许就是因为系统中只有一个实例，这样就导致了单例类的职责过重，违背了“单一职责原则”，同时也没有抽象类，所以扩展起来有一定的困难。
实现：
1）懒汉式——线程不安全
2）饿汉式——线程安全：
采取直接实例化 uniqueInstance 的方式就不会产生线程不安全问题。
但是直接实例化的方式也丢失了延迟实例化带来的节约资源的好处。
3）懒汉式——线程安全
4）双重校验锁——线程安全
5）静态内部类
6）枚举
三：结构型7种 乔装打扮想外住
把类或对象结合在一起形成一个更大的结构。
桥模式（Bridge Pattern）
定义：（将抽象和实现解耦，使得两者可以独立地变化。）
使用场景：
发现类的继承有N层时，可以考虑使用桥梁模式。桥梁模式主要考虑如何拆分抽象和实现。
装饰（Decorator）模式
定义：（动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。）
使用场景：
代理模式（Proxy Pattern）
定义：（为其他对象提供一种代理以控制对这个对象的访问。）
适配器模式（Adapter Pattern）
定义：（将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。）
使用场景：
你有动机修改一个已经投产中的接口时，适配器模式可能是最适合你的模式。比如系统扩展了，需要使用一个已有或新建立的类，但这个类又不符合系统的接口，怎么办？使用适配器模式，这也是我们例子中提到的。
注意事项：
详细设计阶段不要考虑使用适配器模式，使用主要场景为扩展应用中。
享元模式（Flyweight Pattern）
定义：（使用共享对象可有效地支持大量的细粒度的对象。）
使用场景：
注意：
● 享元模式是线程不安全的，只有依靠经验，在需要的地方考虑一下线程安全，在大部分场景下不用考虑。对象池中的享元对象尽量多，多到足够满足为止。
● 性能安全：外部状态最好以java的基本类型作为标志，如String，int，可以提高效率。
外观模式（Facade Pattern）
定义：（要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。）
使用场景：
组合（Composite）模式
定义：（将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。）
使用场景：
注意：
只要是树形结构，就考虑使用组合模式。
四：行为型11种 （访问者通过观察备忘录模版状态命令中介者迭代解释职责策略）
类和对象如何交互，及划分责任和算法。
访问者模式（Visitor Pattern）
定义：（封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。）
观察者模式（Observer Pattern）
定义：（定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。）
使用场景：
注意：
● 广播链的问题
在一个观察者模式中最多出现一个对象既是观察者也是被观察者，也就是说消息最多转发一次（传递两次）。
● 异步处理问题
观察者比较多，而且处理时间比较长，采用异步处理来考虑线程安全和队列的问题。
备忘录模式（Memento Pattern）
定义：（在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。）
使用场景：
注意：
●备忘录的生命期
●备忘录的性能
不要在频繁建立备份的场景中使用备忘录模式（比如一个for循环中）。
模版模式（Template Method Pattern）
定义：（定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。）
状态模式
定义：（当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。）
使用场景：
注意：
状态模式适用于当某个对象在它的状态发生改变时，它的行为也随着发生比较大的变化，也就是说在行为受状态约束的情况下可以使用状态模式，而且使用时对象的状态最好不要超过5个。
命令模式
定义：（将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。）
中介者（mediator）模式
定义：（用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。）
使用场景：
中介者模式适用于多个对象之间紧密耦合的情况，紧密耦合的标准是：在类图中出现了蜘蛛网状结构，即每个类都与其他的类有直接的联系。
迭代器模式（Iterator Pattern）
定义：（它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。）
解释器模式（Interpreter Pattern）
定义：（给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。）
使用场景：
● 重复发生的问题可以使用解释器模式
● 一个简单语法需要解释的场景
注意：
尽量不要在重要的模块中使用解释器模式，否则维护会是一个很大的问题。在项目中可以使用shell、JRuby、Groovy等脚本语言来代替解释器模式，弥补Java编译型语言的不足。
职责链模式
定义：（使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。）
策略模式（Strategy Pattern）
定义：（定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。）
使用场景：
● 多个类只有在算法或行为上稍有不同的场景。
● 算法需要自由切换的场景。
● 需要屏蔽算法规则的场景。
注意事项：具体策略数量超过4个，则需要考虑使用混合模式
最后 加上两个 mvc 既是架构风格 也可以是 设计模式
筛选器模式 java .net 在注册访问时 常用的方法
1、策略 2、观察者、3、装饰 4、工厂 5、单子 6、命令 7、适配器 8模版 9、组合 10、状态
设计模式 是干啥的 ？ 是 对于一类问题的通用解决办法
四要素 ：模式名称、问题、解决方案、效果
五：软件设计原则
1.单一职责
一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性
简单通俗的来说：一个类只负责一项职责。
遵循单一职责原的优点有：
-
可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
-
提高类的可读性，提高系统的可维护性；
-
变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。
单一职责看似简单，实际上在实际运用过程中，会发现真的会出现很多职责扩展的现象，这个时候采用直接违反还会方法上遵循还是完全遵循单一职责原则还是取决于当前业务开发的人员的技能水平和这个需求的时间，如果技能水平不足，肯定会简单的if else 去解决，不会想什么原则，直接实现功能就好了，这也是为什么在很多小公司会发现代码都是业务堆起来的，当然也有好的小公司代码是写的好的，这个也是不可否认的。不过不管采用什么方式解决，心中至少要知道有几种解决方法。
2.里氏替换原则 （Liskov Substitution Principle）
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
3.依赖倒置原则 （Dependence Inversion Principle）
所谓依赖倒置原则（Dependence Inversion Principle）就是要依赖于抽象，不要依赖于具体。实现开闭原则的关键是抽象化，并且从抽象化导出具体化实现，如果说开闭原则是面向对象设计的目标的话，那么依赖倒转原则就是面向对象设计的主要手段。
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
通俗点说：要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
传递依赖关系有三种方式，以上的例子中使用的方法是接口传递，另外还有两种传递方式：构造方法传递和setter方法传递，相信用过Spring框架的，对依赖的传递方式一定不会陌生。
在实际编程中，我们一般需要做到如下3点：
-
低层模块尽量都要有抽象类或接口，或者两者都有。【可能会被人用到的】
-
变量的声明类型尽量是抽象类或接口。
-
使用继承时遵循里氏替换原则。
依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。
4.接口隔离原则 （Interface Segregation Principle）
其原则字面的意思是：使用多个隔离的接口，比使用单个接口要好。本意降低类之间的耦合度，而设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。
原定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。本文例子中，将一个庞大的接口变更为3个专用的接口所采用的就是接口隔离原则。在程序设计中，依赖几个专用的接口要比依赖一个综合的接口更灵活。接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
说到这里，很多人会觉的接口隔离原则跟之前的单一职责原则很相似，其实不然。其一，单一职责原则原注重的是职责；而接口隔离原则注重对接口依赖的隔离。其二，单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节；而接口隔离原则主要约束接口接口，主要针对抽象，针对程序整体框架的构建。
采用接口隔离原则对接口进行约束时，要注意以下几点：
-
接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
-
为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
-
提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
运用接口隔离原则，一定要适度，接口设计的过大或过小都不好。设计接口的时候，只有多花些时间去思考和筹划，才能准确地实践这一原则。
5.迪米特法则（最少知道原则） （Demeter Principle）
为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。也就是说一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制，它要求限制软件实体之间通信的宽度和深度。
定义：一个对象应该对其他对象保持最少的了解。
迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。但是凡事都有度，虽然可以避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系，例如本例中，总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。
6.开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，需要面向接口编程。
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭