设计模式
设计模式作为一套反复使用、多数人知晓、代码设计经验的总结。设计设计模式是为了提高代码的可重用性与代码的鲁棒性等、项目中合理的使用设计模式可以解决很多问题，与之对应，每种模式都有相应的原理对应，每种模式都描述了一个问题及其解决方案。
设计原则
设计模式下需要遵循相关面向对象的设计原则，相关原则及设计模式如下：
| 面向对象设计原则 | 创建型模式（5+1） | 结构性模式（7） | 行为型模式（11） | 行为型模式（11） |
|---|---|---|---|---|
| 单一职责原则 | 简单工厂模式 | 外观模式 | 责任链模式 | 观察者模式 |
| 开闭原则 | 工厂方法模式 | 适配器模式 | 命令模式 | 状态模式 |
| 里氏替代原则 | 抽象工厂模式 | 代理模式 | 解释器模式 | 策略模式 |
| 依赖倒置原则 | 创建者模式 | 装饰模式 | 迭代器模式 | 模板模式 |
| 接口分离原则 | 原型模式 | 桥接模式 | 中介者模式 | 访问者模式 |
| 迪米特原则 | 单例模式 | 组合模式 | 备忘录模式 | |
| 组合/聚合复用原则 | 享元模式 | 观察者模式 |
设计原则详解
1.单一职责模式（Singele Responsibility Principle）
定义：应该有且仅有一个引起类变更的原因。即一个类只负责一项职责。
场景：假设类T负责两个职责:R1,R2,当R1需求发生变更时，需要对类T发生修改，而类T的修改可能会导致职责T2的功能故障。
解决方法：遵循单一职责模式，分别建立两个类T1,T2,使得T1完成R1，T2完成R2；这样使得职责R1需求发生变化需要修改T1时，T2不会发生功能故障。
优势：降低类T的复杂度，将功能分类，模块间功能划分明确，修改一个模块不会造成其他模块的修改，模块之间耦合度降低。
2.开闭原则（Open Closed Principle）
定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
场景：假设方法F实现某功能，当F需要新增功能时，对方法F进行代码修改可能会造成原有功能故障。
解决方法：遵循开闭原则，在新增功能时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
优势：通过扩展已有软件系统,可以提供新的行为,以满足对软件新的需求,提高了软件系统的适应性和灵活性；并提高了可复用性和可维护性。
3.里氏替换原则（Liskov Substitution Principle）
定义：所有引用基类的地方必须能够透明的使用其子类的对象。
- 如果对每一个类型为 T1的对象 o1，都有类型为T2 的对象 o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
- 凡是父类出现的地方,其子类就可以出现,而且调用子类还不能产生多于父类的错误和异常,调用者根本就不要需要知道是子类还是父类对象.但是反过来就不行,子类出现的地方父类未必就能使用。
场景：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由功能P1和P2组成，新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
解决方法：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。【有时候我们可以采用final的手段强制来遵循】
理解：子类可以扩展父类的功能，但不能改变父类原有的功能。 - 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
- 子类中可以增加自己特有的方法。
- 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。【注意区分重载和重写】
- 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
4.依赖倒置原则（Dependence Inversion Principle）
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
场景：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方法：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
理解:相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
5.接口分离原则（Interface Segregation Principle）
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
场景：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
解决方法：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
6.迪米特原则（Demeter Principle）
定义：一个对象应该对其他对象保持最少的了解。
场景：类 A 通过接口 I 依赖类B，类C通过接口 I 依赖类D，如果接口 I 对于类 A 和类 B 来说不是最小接口，则类 B 和类 D 必须去实现他们不需要的方法。
解决方法：将臃肿的接口I拆分为独立的几个接口，类 A 和类 C 分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
理解：就是一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量地的将逻辑封装在类的内部，对外除了提供的public方法，不对外泄漏任何信息。
7.组合/聚合复用原则（Composite Aggregate Reuse Principle）
定义：当一个类想使用另一个类的功能时,优先使用对象的组合,而不是继承,尽量多使用组合
优势：利于构建可维护,可复用,可扩展和灵活性好的软件系统。
理解：合成聚合复用原则是值在一个新对象中通过组合关系使用原来已有的一些对象,使之成为新对象的一部分,通过使用已有对象的API完成已有功能的调用。为什么要是用合成聚合,尽量不要使用继承?
- 继承破坏包装,把超类的实现细节直接暴露给子类,不利于信息的隐匿。
- 如果父类发生改变,会引发一系列子类的改变,类之间耦合度高。
- 继承是一种静态功能的使用,在运行的过程中不能发生改变,聚合复用可以动态传入子类对象实现功能动态改变。
