01. Java设计模式的设计原则
常见的7中面向对象设计原则
一、单一职责原则
一个类中负责一个功能领域中的相应职责
二、开闭原则
软件实体应对扩展开放，而对修改关闭
- 软件越大，寿命越长；需要方便扩展，扩展时无需修改现有代码。
- 抽象化设计<抽象类，接口>：开闭原则的关键，抽象层和实现层分离；如果需要改动系统的行为，只需要添加新的具体类实现新的业务功能，不修改已有的代码从而扩展系统的功能
不动源代码，只需要动配置文件，也是符合开闭原则的软件系统。
三、里氏代换原则
所有引用基类对象的地方都能够透明地使用其子类对象【多态】
- 里氏代换原则是实现开闭原则的重要方式之一
- 在程序中尽量使用基类对对象进行定义，在运行时在确定其子类的类型。用子类对象替换父类对象(多态)。
1). 注意
- 子类必须实现(抽象)父类/接口中所有的抽象方法。
- 尽量吧父类设计为抽象类或者接口。
- Java 会根据多态机制进行编译检查，但是检查是有局限性的。
四、依赖倒转原则
抽象不应该依赖于细节，细节应该依赖于抽象（针对接口编程，而不是针对实现编程）
在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不是用具体类类做这些事。为了确保该原则的引用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用在子类中增加的新方法。
在程序中尽量使用抽象层进行编程，而将具体类写配置文件中，如果系统行为发生变化，只需要对抽象层进行扩展，修改配置文件，无需改变原有系统的源代码，满足开闭原则。
依赖倒转中，当一个对象与其他对象发生依赖关系。在该对象中声明对应的抽象类/接口。然后通过 构造函数/setter/注解注入 的方式进行注入。(DependencyInjection, DI)在程序运行时确定执行的对象。
1). 以下三个原则一般会同时出现
- 开闭原则 目标(拓展开放，修改关闭)
- 里氏代换原则 基础(多态，基类可以，子类必须可以)
- 依赖倒转原则 手段(DI)
五、接口隔离原则
使用多个专门的接口，而不是使用单一的总接口
- 接口尽量小，细化、但是不能太细，否则不利于维护。
- 方法尽量少。
- 职责单一。
六、合成复用原则
尽量使用对象组合/聚合，而不是继承来达到复用的目的
- 首先考虑组合/聚合的方式进行设计，这样系统更加灵活，降低类之间的耦合度，一个类的变化对其他类造成的印象相对较少。【黑箱复用】
- 然后再考虑继承(并谨慎使用)，要严格遵循里氏代换原则；
1). 继承可能造成的问题
- 破坏系统的封装性。如果基类的内部细节发生变化，子类的实现也不得不发生变化。【白箱复用】
- 从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性。
- 继承只能在有限的环境下使用(类没有被声明为不能被继承，就是没有被final修饰的情况下才能使用继承)
2). 组合/聚合 方式相对于 继承 的优势
- 耦合度低，成员对象的变化对新对象的影响不大，可以在新对象中根据实际需要有选择性地调用成员对象的操作
- 合成复用可以在运行时动态进行，新对象可以动态地引用与成员对象类型相同的其他对象。
3). 对象之间的关系
- is-a关系：关系密切,可以使用继承。
- has-a关系：表示某一角色具有某一项责任，使用组合。
在使用组合的方式，同时利用里氏代换原则，依赖倒转原则。
七、迪米特法则(最少知识法则)
一个软件实体应当尽可能少地与其他实体发生相互作用，迪米特法则可以降低系统的耦合度，使类与类之间保持松散的耦合关系。
1). 特殊的几种定义形式
- 不要和“陌生人”说话
- 只与对象的“直接朋友”通信，“直接朋友” 如下(其他情况的为“陌生人”)
- 当前对象本身(this)
- 以参数形式传入到当前对象方法中的对象
- 当前对象的成员对象
- 当前成员对象(集合类型数据)中的元素
- 当前对象所创建的对象
【降低耦合的第三者】：在设计系统时，应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，这两个对象就不应该发生任何直接的相互作用，如果其中一个对象需要调用另一个对象的某一个方法，可以通过【第三者】转发这个调用，降低耦合度。
2). 注意：
- 在类的划分上，尽量创建松耦合的类，耦合度越低，越利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大的波及；
- 在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限。(private)
- 在类的设计上，只要有可能，一个类型应当设计成不变类；
- 在对其他类的引用上，一个对象对其他对象的引用应当降到最低。
附录
一、最常见的7种面向对象设计原则排行榜
| 设计原则名称 | 定义 | 使用频率 |
|---|---|---|
| 开闭原则 (Open-Closed Principle, OCP) | 软件实体应对扩展开放，而对修改关闭 | ★★★★★ |
| 里氏代换原则 (Liskov Substitution Principle, LSP) | 所有引用基类对象的地方能够透明地使用其子类的对象 | ★★★★★ |
| 依赖倒转原则 (Dependence Inversion Principle, DIP) | 抽象不应该依赖于细节，细节应该依赖于抽象 | ★★★★★ |
| 单一职责原则 (Single Responsibility Principle, SRP) | 一个类只负责一个功能领域中的相应职责 | ★★★★☆ |
| 合成复用原则 (Composite Reuse Principle, CRP) | 尽量使用对象组合，而不是继承来达到复用的目的 | ★★★★☆ |
| 迪米特法则 (Law of Demeter, LoD) | 一个软件实体应当尽可能少地与其他实体发生相互作用 | ★★★☆☆ |
| 接口隔离原则 (Interface Segregation Principle, ISP) | 使用多个专门的接口，而不使用单一的总接口 | ★★☆☆☆ |
二、常见设计模式使用频率排行榜
| 模式名称 | 学习难度 | 使用频率 |
|---|---|---|
| 抽象工厂模式(创建型) Abstract Factory Pattern | ★★★★☆ | ★★★★★ |
| 迭代器模式(行为型) Iterator Pattern | ★★★☆☆ | ★★★★★ |
| 观察者模式(行为型) Observer Pattern | ★★★☆☆ | ★★★★★ |
| 工厂方法模式(创建型) Factory Method Pattern | ★★☆☆☆ | ★★★★★ |
| 外观模式(结构型) Façade Pattern | ★☆☆☆☆ | ★★★★★ |
| 代理模式(结构型) Proxy Pattern | ★★★☆☆ | ★★★★☆ |
| 组合模式(结构型) Composite Pattern | ★★★☆☆ | ★★★★☆ |
| 命令模式(行为型) Command Pattern | ★★★☆☆ | ★★★★☆ |
| 适配器模式(结构型) Adapter Pattern | ★★☆☆☆ | ★★★★☆ |
| 策略模式(行为型) Strategy Pattern | ★☆☆☆☆ | ★★★★☆ |
| 单例模式(创建型) Singleton Pattern | ★☆☆☆☆ | ★★★★☆ |
| 原型模式(创建型) Prototype Pattern | ★★★☆☆ | ★★★☆☆ |
| 桥接模式(结构型) Bridge Pattern | ★★★☆☆ | ★★★☆☆ |
| 装饰模式(结构型) Decorator Pattern | ★★★☆☆ | ★★★☆☆ |
| 状态模式(行为型) State Pattern | ★★★☆☆ | ★★★☆☆ |
| 简单工厂模式(创建型) Simple Factory Pattern | ★★☆☆☆ | ★★★☆☆ |
| 模板方法模式(行为型) Template Method Pattern | ★★☆☆☆ | ★★★☆☆ |
| 建造者模式(创建型) Builder Pattern | ★★★★☆ | ★★☆☆☆ |
| 职责链模式(行为型) Chain of Responsibility Pattern | ★★★☆☆ | ★★☆☆☆ |
| 中介者模式(行为型) Mediator Pattern | ★★★☆☆ | ★★☆☆☆ |
| 备忘录模式(行为型) Memento Pattern | ★★☆☆☆ | ★★☆☆☆ |
| 解释器模式(行为型) Interpreter Pattern | ★★★★★ | ★☆☆☆☆ |
| 享元模式(结构型) Flyweight Pattern | ★★★★☆ | ★☆☆☆☆ |
| 访问者模式(行为型) Visitor Pattern | ★★★★☆ | ★☆☆☆☆ |
