面向对象七大设计原则-复习

面向对象七大设计原则（SOLID原则）

注：S O L I D原则是下面七大原则中的前5个首字母拼写

1、单一职责原则

（Single Responsibility Principle）

解释：对于单一职责原则，可以理解为一个类只负责一个功能领域中的相应职责， 即一个类不要负责太多“杂乱”的工作。

在软件系统中，如果一个类承担的职责过多，就等于把这些职责耦合在一起， 一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时设计或遭受到意想不到的破坏。

以项目开发为例，如果项目组成员每个人的职责都很明确，可以专心开发自 己负责的模块，则项目成果的质量往往很高。相反，如果职责不清晰，分工就会混乱。

总结： 一个类不要负责太多事情,否则导致类内部耦合度太高，不利于扩展

优点：高内聚、低耦合

---

2、开闭原则

（Open Close Principle）

开闭原则是面向对象设计的核心

解释：在软件系统开发过程中，软件的需求往往会随着时间的推移而发生变化。因此，进行软件设计时需要考虑怎样的设计才能面对需求的改变却可以相对保持稳定，从而使得系统可以在第一个版本以后不断推出新的版本,这时便可以以开闭原则作为指导。

为了满足开闭原则，需要对系统进行抽象化设计，抽象化是开闭原则的关键。在进行软件设计时，一般先评估出最有可能发生变化的类，然后构造抽象来隔离那些变化。当变化发生时，无须对抽象层进行任何改动，只需要增加新的具体类来实现新的业务功能即可，实现在不修改已有代码的基础上扩展系统的功能，达到开闭原则的要求。

总结：开闭原则即对扩展开放，对修改封闭。

优点:

（1）适应性、灵活性高

（2）稳定性、延续性好

（3）可复用性与可维护性

---

3、里式替换原则

（Liskov Substitution Principle）

由来：1987 年由麻省理工学院计算机科学实验室的里斯科夫（Liskov）女士在“面 向对象技术的高峰会议”上发表的一篇文章《数据抽象和层次》里提出来的，她提出：继承必须确保超类所拥有的性质在子类中仍然成立.

里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继 承，什么时候不应该使用继承。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。

继承优点：

（1）提高代码的复用性（每个子类有拥有父类的属性和方法）

（2）提高代码的可扩展性

继承缺点：

（1）继承是侵入性的（只要继承，就必须拥有父类的属性和方法，体系结构复杂）

（2）继承机制增加了耦合性(父类被子类继承，父类出现修改情况时，需要考虑子类的修改)

（2）继承具有约束性(子类需要拥有父类的属性和方法，子类多了一些约束)

里式替换原则解释：通俗的讲：任何基类可以出现的地方，子类一定可以出现。所以，**子类可以扩展父类的功能，但不能改变父类原有的功能。**换句话说，子类继承父类时除添加新的方法完成新增功能外尽量不要重写父类的方法。

总结：里氏替换原则并不是鼓励使用继承，而是当你不得已使用继承时，需要增加一些约束，避免出现不良影响。例如不能影响父类原有的功能

---

4、接口隔离原则

（Interface Segregation Principle，ISP）

解释：可以根据不同的功能设计接口,不要将所有的功能设计到一个接口中， 让子类可以根据自己的需要去实现不同的接口，不用实现一些不必要的功能

接口分隔原则总的来说是鼓励使用接口的，只是进行了一定的约束，便于更好的发挥接口的作用

总结：使用多个接口，而不使用单一的总接口，不强迫新功能实现不需要的方法

缺点：增加了代码的复杂性

优点：提高了代码的灵活性

---

5、依赖倒置原则

（Dependence Inversion Principle）

依赖倒转原则是鼓励使用接口

什么是依赖？在程序设计中，如果一个模块a使用/调用了另一个模块b，我们称模块a依赖模块b。

高层模块与低层模块：往往在一个应用程序中，我们有一些低层次的类，这些类实现了一些基本的操作，我们称之为低层模块；另外有一些高层次的类，这些类封装了某些复杂的逻辑，并且依赖于低层次的类，这些类我们称之为高层模块

依赖倒置解释：程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。也就是针对抽象层编程，面向接口编程。

抽象接口是对低层模块的抽象，低层模块继承或实现该抽象接口。这样，高层模块不直接依赖低层模块，而是依赖抽象接口层。抽象接口也不依赖低层模块的实现细节，而是低层模块依赖（继承或实现）抽象接口。

类与类之间都通过抽象接口层来建立关系。

---

6、迪米特原则

（Law Of Demeter）

定义：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性

迪米特原则（Law of Demeter）又叫作最少知识原则（The Least Knowledge Principle），通俗的来讲，就是一个类对自己依赖的类了解的的越少越好。也就是说，从被依赖者的角度来说，尽量将逻辑封装在类的内部，对外除了提供的 public 方法，不泄露任何信息

迪米特原则简单定义：只与你的直接朋友交谈，不与“陌生人”说话

“直接朋友”：我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。

迪米特法则的目的：降低类之间的耦合（核心）。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块相互独立，相互之间不存在依赖关系。

狭义的迪米特法则的缺点：遵循类之间的迪米特法则会使一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有之间的关联。但是，这会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。

---

7、组合/聚合原则

（Composite/Aggregate Reuse Principle CARP）

聚合：表示整体与部分的关系，表示“含有”，整体由部分组合而成，部分可以脱离整体作为一个独立的个体存在

组合：是一种更强的聚合，部分组成整体，而且不可分割，部分不能脱离整体而单独存在。在合成关系中，部分和整体的生命周期一样，组合的新的对象完全支配其组成部分，包括他们的创建和销毁。

组合与聚合的区别：

（1）简单来讲，组合是一种较为紧密的关系，从生命周期上看，部分和整体是共存亡的关系。聚合则是一种较为松散的关系，部分和整体的生命周期未必一致。

（2）在实际代码中，组合关系中部分的实例化在整体中进行。聚合关系中，部分的实例化过程在整体外进行，然后通过某种方式注入给整体。

（3）另一种表现可能是，组合是静态聚集，聚合是动态聚集。

---

8、总结

（1） 开闭原则：要求对扩展开放，对修改关闭

（2） 里氏替换原则：不要破坏继承体系

（3） 依赖倒置原则：要求面向接口编程

（4） 单一职责原则：实现类职责要单一

（5） 接口隔离原则：在设计接口的时候要精简单一

（6） 迪米特法则：只与直接的朋友的通信

（7） 合成复用原则：尽量使用聚合和组合的方式，而不是使用继承

9、设计原则的核心思想

（1） 找出应用中可能需要变化之处，独立出来，不要和不需要变化的代码混在一

起

（2） 针对接口编程，而坏是针对实现编程

（3） 为了交互对象的松耦合设计而努力

遵循设计原则：就是为了让程序高内聚，低耦合