一.设计模式
1.概念
设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式具有“适应需求变化”的优点。
基本原则：模块应对外扩展开放，而对修改关闭，要针对接口，而不是组合，抽象不应该依赖于细节，细节应当依赖于抽象
2.基本分类：共23种模式 3种分类 创建型、 结构型、 行为型
（1）对象实例化的模式，创建型模式用于解耦对象的实例化过程。
抽象工厂模式（Abstract Factory Pattern）：
定义：（为创建一组相关或相互依赖的对象提供一个接口，而且无须指定它们的具体类。）
工厂方法模式
定义：（定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。）
生成器模式（Builder Pattern）
定义：（将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。）
原型模式（Prototype Pattern）
定义：（用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。）
单子模式 （Singleton Pattern）
定义：（确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。）
（2）结构型7种 乔装打扮想外住
把类或对象结合在一起形成一个更大的结构。
桥模式（Bridge Pattern）
定义：（将抽象和实现解耦，使得两者可以独立地变化。）
装饰（Decorator）模式
定义：（动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。）
代理模式（Proxy Pattern）
定义：（为其他对象提供一种代理以控制对这个对象的访问。）
适配器模式（Adapter Pattern）
定义：（将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。）
享元模式（Flyweight Pattern）
定义：（使用共享对象可有效地支持大量的细粒度的对象。）
外观模式（Facade Pattern）
定义：（要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。）
组合（Composite）模式
定义：（将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。）
（3）行为型11种 （访问者通过观察备忘录模版状态命令中介者迭代解释职责策略）
类和对象如何交互，及划分责任和算法。
访问者模式（Visitor Pattern）
定义：（封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。）
观察者模式（Observer Pattern）
定义：（定义对象间一种一对多的依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。）
备忘录模式（Memento Pattern）
定义：（在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。）
模版模式（Template Method Pattern）
定义：（定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。）
状态模式
定义：（当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。）
命令模式
定义：（将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。）
中介者（mediator）模式
定义：（用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。）
迭代器模式（Iterator Pattern）
定义：（它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。）
解释器模式（Interpreter Pattern）
定义：（给定一门语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。）
职责链模式
定义：（使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。）
策略模式（Strategy Pattern）
定义：（定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。）
设计模式 是干啥的 ? 是 对于一类问题的通用解决办法
四要素 ：模式名称、问题、解决方案、效果
二.软件设计原则
1.单一职责
一个类只负责一项职责。也是模块化程序设计的体现。
2.里氏替换原则 （Liskov Substitution Principle）
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。
里氏代换原则是对实现抽象化的具体步骤的规范。
3.依赖倒置原则 （Dependence Inversion Principle） 11111
所谓依赖倒置原则（Dependence Inversion Principle）就是要依赖于抽象，不要依赖于具体。
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
通俗点说：要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。
4.接口隔离原则 （Interface Segregation Principle）
其原则字面的意思是：使用多个隔离的接口，比使用单个接口要好。
本意降低类之间的耦合度，而设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。
原定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。
也就是说，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
5.迪米特法则（最少知道原则） （Demeter Principle）
为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
也就是说一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块.
定义：一个对象应该对其他对象保持最少的了解。
所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。
6.开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。
所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，需要面向接口编程。
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭
标签：软件开发,原则,对象,Pattern,模式,接口,定义 From： https://blog.csdn.net/xieliru/article/details/143066263