文章目录
七大原则
开闭原则 （Open Close Principle）
- 对扩展开放，对更改关闭
- 保证以前代码的准确性，使开发者更专注于新扩展的代码上
单一职责原则 （Single Responsibility Principle）
- 一个类只负责一个功能领域的职责
- 降低类的复杂度，当修改一个功能时，降低对其他功能的影响，提供类的可读性
里氏替换原则 （Liskov Substitution Principle）
- 任何基类出现的地方，子类一定可以出现
- 在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象，开闭原则实现的手段之一
依赖倒转原则 （Dependence Inversion Principle）
- 针对接口编程，抽象不依赖于细节，细节应依赖于抽象
- 多数情况下，开闭原则，里氏替换原则，依赖倒转原则会同时出现，开闭原则是目标，里氏替换原则是基础，依赖倒转是手段。
接口隔离原则 （Interface Segregation Principle）
- 使用多个专门的接口，不使用单一的总接口
- 当一个接口太大时，我们需要把他拆分成更小的接口，但不能违反单一职责原则，每个接口应该承担一种相对独立的角色，不该干的事情不干，该干的事情都要干。
迪米特法则 （Law Of Demeter）
- 一个实体应当尽量少的与其他实体发生相互作用，也就最少知道原则，一个对象尽量让其它对象保持最少的了解
- 应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的 某一个方法的话，可以通过第三者转发这个调用。
合成复用原则（Composite Reuse Principle）
- 尽量使用组合而非继承
- 就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，新的对象通过这些对象的委派达到复用已有功能的目的
单例模式
只涉及一个负责实例化自身的类，以确保它创建的实例不会超过一个，并且提供一个全局访问控制点
- 每个类在内存中只有一个实例
- 实例必须由该类创建
- 一个实例必须被整个系统访问
桥模式 bridge
从现实中分离抽象，这样两者可以独立变化
Abstraction：抽象定义了抽象接口
RefinedAbstraction：使用对Implementor类型的对象的引用来实现Abstraction接口
Implementor：定义实现类的接口，这个接口不需要直接对应Abstraction接口，可以有很大不同
例：现在我们需要供应三种尺寸的蜡笔(大、中、小)，有五种颜色(红、绿、蓝、白、黑)。根据桥状图案，设计一个系统来制作彩色蜡笔。
观察者模式 observer
定义对象间的一种一对多的依赖关系，以便当一个对象的状态改变时，所有依赖它的对象都得到通知并自动刷新
责任链模式 Chain of Responsibility
在编写代码过程中，经常会发生由一个对象生成的事件需要另一个对象处理的情况，有时候还会被拒绝访问需要处理的对象
责任链设计模式允许对象发送命令，但不知道哪个对象将接收和处理它。请求从一个对象发送到另一个对象，使他们成为链的一部分，这个链中的每个对象都可以处理/传递命令。
为解除请求的发送者和接受者之间的解耦，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它
学生需要申请奖学金，并提交申请表，该申请表需要一层层批准：辅导员，系主任，院长…
命令模式 Command
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队货记录请求日志，以及支持可取消的操作
- 将请求封装在对象中
- 允许参数化具有不同请求的客户端
- 允许将请求保存在队列中
- 命令在发送方和接收方之间解耦
迭代器模式 Iterator
提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象内部表示
中介者模式 Mediator
用一个中介对象来封装一系列对象的交互；中介对象使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互
享元模式 Flyweight Pattern
运用共享技术有效地支持大量细粒度的对象。
适用性
当以下所有的条件都满足时，可以考虑使用享元模式：
- 一个应用程序使用了大量的对象。
- 完全由于使用大量的对象，造成很大的存储开销。
- 对象的大多数状态都可变为外部状态。
- 如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象。
- 应用程序不依赖于对象标识。由于Flyweight对象可以被共享，对于概念上明显有别的对象，标识测试将返回真值。
满足以上的这些条件的系统可以使用享元对象。
最后，使用享元模式需要维护一个记录了系统已有的所有享元的表，而这需要耗费资源。因此，应当在有足够多的享元实例可供共享时才值得使用享元模式。
组合模式 composite
将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得客户对单个对象和复合对象使用具有一致性
装饰模式 Decorator
动态地给一个对象添加一些额外的功能
- 动态、透明的方式给单个对象添加职责。
- 如果不适合适用子类来进行扩展的时候，可以考虑适用装饰模式。
- 避免子类数目爆炸性增长
Component: 定义一个对象接口,可以给这些对象动态地添加职责.
ConcreteComponent: 定义一个对象,可以给这个对象添加职责.
Decorator: 持有一个指向Component对象的引用,并定义一个与Component的接口一致的接口.
ConcreteComponent: 向组件添加职责
外观模式 Facade
为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
简单工厂模式
用户不需要知道产品类别，只需要提供一个参数
让客户类永远接触不到产品类，只是让用户知道抽象或接口类
工厂方法模式
简单工厂模式的问题就是：类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改
工厂方法模式添加了concrete factory和abstract factory——遵循open-close原则和dependency reverse 原则
工厂是一个抽象creator，只是要求具体的工厂生产一个产品
如下例：
假如增加其他品牌鼠标，工厂类需要修改，如何解决？就用到工厂方法模式，创建一个工厂接口和创建多个工厂实现类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。
工厂抽象模式
抽象工厂提供了创建一系列相关对象的接口，而无需显式地指定它们的类
factory method 处理来自多个生产商的一组产品
factory abstract 处理来自多个生产商的多组产品
抽象工厂模式中我们可以定义实现不止一个接口，一个工厂也可以生成不止一个产品类，抽象工厂模式较好的实现了“开放-封闭”原则，是三个模式中较为抽象，并具一般性的模式。我们在使用中要注意使用抽象工厂模式的条件
例：新增一个键盘产品类
