设计原则

设计思想

设计思想的目的是为了提高代码的可读性，可扩展性，可维护性。

设计原则

O开闭原则

对扩展开放、修改关闭，找出不变的隔离封装。
添加一个新的功能，应该是通过在已有代码基础上扩展代码（新增模块、类、方法、属性等），而非修改已有代码（修改模块、类、方法、属性等）的方式来完成。
做需求时，对需求整体脉络有初步梳理，哪些是不变的，哪些未来可能需求变更、需要扩展。
目标：新需求不修改原来的代码或者极小的改动情况下，新功能代码能灵活的插入到原逻辑扩展点。

S单一职责原则

一个类、方法、接口只完成一件事情。避免设计大而，功能耦合到一起的类，也就是常说的高内聚。类职责单一 依赖和被依赖的其他类也就对应减少，也就是常说的低耦合。

I接口隔离原则

接口的使用者、调用者，不应强迫依赖不需要的功能接口。
单一职责和接口隔离看似差不多，其实侧重点不一样。
单一职责是针对类，接口，方法的设计。
接口隔离一方面侧重接口的设计，另一方面提供了验证接口职责是否单一的标准，调用方如果只是用到了部分接口，则说明接口设计不够职责单一。

L里式替换原则

子类对象能够替换父类对象出现的任何地方，且不影响程序功能逻辑的正确性。
里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

D依赖倒置原则

• 高层次的模块不应该依赖低层次的模块，他们都应该依赖于抽象。
• 抽象不应该依赖于具体，具体应该依赖于抽象。
• 高层次模块依赖接口和抽象类，创建接口时需要用到创建反转，即变化的逻辑（选择依赖的具体实现类）转移到其他地方控制比如工厂容器，也就是控制反转IOC。
• IoC容器在运行期间，动态地将某种依赖关系注入到对象之中，也就是依赖注入（构造函数，set等方式）。

迪米特（最少知道）原则

• 从被依赖者的角度来说：只暴露应该暴露的方法或者属性，即在编写相关的类的时候确定方法/属性的权限
• 从依赖者的角度来说，只依赖应该依赖的对象
• 一个对象应该对其他对象保持最少的了解。
• 一个类应该对其依赖的类知道的越少越好，被依赖的类把功能逻辑都封装到public方法内，不对外泄漏任何信息。
• 另一种解释，只与最直接熟悉的朋友交互。
• 直接（熟悉）的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系， 我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。
  其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量 的形式出现在类的内部。
• 一个类应该尽量不要知道其他类太多的东西，不要和陌生的类有太多接触。

组合优于继承

基于单一职责。有一个XX功能比是一个XX功能好。

总结：
1.分离变化与不变的内容，变化的进行封装，以免影响其他部分。
2.面向接口编程，而不是针对实现编程。
3.“有一个”可能比“是一个”更好，多用组合，少用继承。
4.为了交互对象之间的松耦合设计而努力。
5. 依赖抽象而不依赖具体
6. 只和朋友交谈
7. 别找我，我会找你
8. 类应该只有一个改变的理由

参考：
https://www.toutiao.com/i6794989862886834701/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1595396220&app=news_article&utm_source=weixin&utm_medium=toutiao_android&use_new_style=1&req_id=2020072213370001002202604021ABA409&group_id=6794989862886834701
https://www.cnblogs.com/fuchongjundream/p/3873073.html
https://www.cnblogs.com/wwj99/p/12801210.html
https://www.cnblogs.com/leeSmall/p/10010006.html