面向对象六大设计原则

简述：

本文主要阐述面向对象六大基本设计原则的基本：
单一接口原则、里氏替换原则、依赖倒置原则、开闭原则、接口隔离原则、迪米特原则

1. 单一职责原则：

• 一个类或者接口只负责一个功能领域中的相应职责，就一个类而言，应该只有一个引起它变化的原因。
• 在实际应用中，多选择采用**针对方法（接口）**的单一职责原则
• 优点：
  • 低耦合性，影响范围小
  • 降低类的复杂度，职责分明，提高了可读性
  • 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

2. 开闭原则：

• 一个软件实体（软件实体可以指一个软件模块，一个由多个类组成的局部结构，一个独立的类，甚至一个方法）应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。

• 开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定灵活的系统。

• 优点：

  1. 提高系统的灵活性
  2. 提高系统可复用性和可维护性
  3. 是最基础的设计原则，其他五个设计原则都是开闭原则的具体形态

• 开闭原则的具体体现：

  1.抽象约束

  1. 通过接口或抽象类约束扩展,对扩展进行边界限定,不允许出现在接口或抽象类中不存在的public方法
  2. 参数类型、引用对象尽量使用接口或抽象类,而不是实现类
  3. 抽象层尽量保持稳定,一旦确定不允许修改接口或抽象类一旦定义,应立即执行,不能有修改接口的想法,除非是彻底的大返工

  2.元数据控制模块行为

  元数据: 用来描述环境和数据的数据,通俗的说就是配置参数.

  通过扩展一个子类,修改配置文件,完成了业务的变化,也是框架的好处

  3.制定项目章程

  4.封装变化

  对变化的封装包含两层含义:

  1. 将相同的变化封装到一个接口或抽象类中
  2. 将不同的变化封装到不同的接口或抽象类中

  不能有两个不同的变化出现在同一个接口或抽象类中.封装变化,找出预计的变化或不稳定的点,为这些变化点创建稳定的接口,准确的讲是封装可能发生的变化.23个设计模式都是从各个不同的角度对变化进行封装的.

3. 里氏替换原则（LSP）：

• 第一种定义：如果对每个类型为S的对象o1，都有类型为T的对象o2，对于所有以T定义的程序P，当o1替代o2时，P的行为没有改变，那么S就是类型为T的子类型。

• 第二种定义：使用父类引用的方法，必须能够透明的使用子类的对象

  通俗的讲就是父类出现的地方子类也能够胜任，并且不会产生任何问题。

• 强调的是设计和实现要依赖于抽象而非具体，子类只能去扩展父类，而不是隐藏或者覆盖基类。即设计不要破坏继承关系

• 优点：

  • 开闭原则的体现，约束继承泛滥
  • 提高系统的健壮性，扩展性和兼容性
  • 在代码升级时可以保持非常好的兼容性，即使增加子类，原有的子类或者父类还可以继续运行。

• 里氏替换原则隐含的四个约束：

  1. 子类必须完全实现父类的抽象方法，但是不得重写父类的已实现方法（非抽象）

     理解：如果子类想重写父类已有的非抽象方法，则可以在子类中另起一个类似父类的那个方法，方法名不同，而不是去覆盖父类的方法。

  2. 子类可以增加自己特有的方法

  3. 当子类重写或者实现父类的方法时，方法的形参要比父类方法的形参更加宽松（部分多态的思想）

  4. 当子类的方法实现父类的（抽象）方法时，子类的返回值类型必须要窄于父类的返回值类型（部分多态的思想和自动类型转换）

• 总的来说，里氏替换原则可以让Java继承的优点发挥更强大全面的作用，而让继承的弊端和局限性尽量避免

4. 依赖倒置原则（DIP）

• 定义：高层模块不应该依赖底层模块，二者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。
• 通俗点说就是要求对抽象进行编程，不要对实现进行编程。
• 实现开闭原则的关键就是抽象化，并且从抽象指定具体化的实现
• 如果说开闭原则是面向对象设计的主要目标的话，那么依赖倒置原则就是面向对象设计的主要手段
• 依赖倒置原则中的抽象一般啊多指接口和抽象类，细节一般指具体的实现
• 依赖倒置原则的核心思想是面向接口编程
• 使用接口或者抽象类的目的是制定好规范和契约，而不去设计任何具体的操作，具体的操做和细节留给他们的实现类去完成
• 在实际编程中的体现：
  • 低层模块尽量都要有抽象类或者接口，或者两者都有，因为极大概率会被自己或者他人重复使用
  • 变量的声明类型尽量使用抽象类或者接口
  • 使用继承时应尽可能的遵循里氏替换原则

5. 接口隔离原则（ISP）

• 定义：客户端不应该依赖它不需要的接口，一个类对另一个类或者接口的依赖应该建立在最小的情况下，也就是最小的接口上

  也就是说使用多个隔离的，功能尽量单一的接口，比使用多个功能的一个接口要好。意思是要降低类之间的耦合度，接口中的全部方法未必全部都要用到。所以设计接口的时候保持单一职责原则，就可以做到需要哪个功能就添加一个接口，从而降低了程序间的依赖和耦合。

• 接口隔离原则简单理解就是：建立单一接口，不要建立庞大臃肿的接口，应该尽量细化接口，使得接口中的方法尽量少

• 运用接口隔离原则，一定要适度，接口设计的过大或者过小都不好，设计接口的时候一定要多花一些时间去思考和筹划，才能准确的实现这一原则

• 单一职责原则和接口隔离原则有什么区别呢？

  个人觉的单一职责原则更加广泛，更加细致，注重的是职责，是约束类，接口，方法的一个基本思想。它针对的是程序中实现的每一个细节。

  而接口隔离原则主要约束接口要尽量简化，主要针对抽象，针对程序的整体架构。

6. 迪米特原则（Demeter Priciple）

• 迪米特法则也叫最少知道原则
• 定义：一个对象应该对其他对象保持最少的了解
• 自从我们接触编程开始，就知道了软件编程的总的原则：低耦合，高内聚。无论是面向过程编程还是面向对象编程，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。低耦合的优点不言而喻，但是怎么编程才能做到低耦合呢，迪米特法则很好地体现了这一点
• 理解：通俗的来讲，就是一个类对自己以来的类知道的越来越少，也就是说，对于被依赖的类来说，无论逻辑多么复杂，都尽量的讲逻辑封装在类的内部，对外除了提供的public方法，不对外泄露任何信息
• 迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系，但是凡事都有度，虽然可以避免非直接的类通信，但是要通信，必然会通过一个中介来联系，如果迪米特法则用的过度，则导致这个中介过于庞大和繁琐，会使系统的复杂度变大。
• 所以使用迪米特法则的时候要反复权衡，既要做到结构清晰又要高内聚低耦合

---

P.S.此文是本人综合了其他博主以及相关书籍写下的一些对于面向对象设计原则的看法和理解，如有错误或不当理解，请评论区不吝赐教。