面向对象设计原则

面向对象设计原则

0.前言

• 设计原则部分内容主要来自《大话设计模式》一书，同时参考了以下博客
  • 史上最全的设计模式导学目录

1.面向对象设计模式原则概述

• 对于面向对象软件系统的设计而言，在支持可维护的同时，提高系统的可复用性是一个至关重要的问题，如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一。在面向对象设计中，可维护性的复用是以设计原则为基础的。每一个原则都蕴含一些面向对象设计的思想，可以从不同的角度提升一个软件结构的设计水平。
• 面向对象设计原则为支持可维护性复用而诞生，这些设计原则蕴含在很多设计模式中，它们是从许多设计方案中总结出的指导性原则。面向对象设计原则也是我们用于评价一个设计模式使用效果的重要指标之一，总之，面向对象设计原则在设计模式的产生以及优化方面扮演很重要的角色。

---

• 最常见的7种面向对象设计原则如下表所示：

设计原则名称	定义	使用频率
单一职责原则(Single Responsibility Principle, SRP)	一个类只负责一个功能领域中的相应职责	★★★★☆
开闭原则(Open-Closed Principle, OCP)	软件实体应对扩展开放，而对修改关闭	★★★★★
里氏代换原则(Liskov Substitution Principle, LSP)	所有引用基类对象的地方能够透明地使用其子类的对象	★★★★★
依赖倒转原则(Dependence Inversion Principle, DIP)	抽象不应该依赖于细节，细节应该依赖于抽象	★★★★★
接口隔离原则(Interface Segregation Principle, ISP)	使用多个专门的接口，而不使用单一的总接口	★★☆☆☆
合成复用原则(Composite Reuse Principle, CRP)	尽量使用对象组合，而不是继承来达到复用的目的	★★★★☆
迪米特法则(Law of Demeter, LoD)	一个软件实体应当尽可能少地与其他实体发生相互作用	★★★☆☆

2.单一职责模式

• 单一职责模式：对于一个类而言，应该仅有一个引起它变化的原因。

---

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

---

• 软件设计真正要做的许多内容，就是发现职责并把职责相互分离。其实要去判断是否应该分离出类来，也不难，如果你能够想到多余一个的动机去改变一个类，那么这个类就具有多余一个的职责，就应该考虑类的职责分离。

3.开闭原则

• 开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改
• 扩展一般指新增类，修改一般指改动现有代码。
• 这个原则有两个特征：
  • 对于扩展是开放的；对于更改是封闭的。
    • 我们在做任何系统的时候，都不要指望系统一开始是需求确定，就不再变化。这是不现实也不科学的想法，而既然需求是一定会变化的，那么如何在面对需求的变化是，设计的软件可以相对容易修改，不至于说，新需要一来，就要把整个程序推倒重来。怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？
    • 核心关注点（不可动摇点）的关闭，次要因素的开放。

3.1 何时应对变化

• 开放封闭的意思是说，你设计的时候，时刻要考虑，尽量让这个类足够好，写好了就不要去修改，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。

• 但不可能做到写完一个类就再也不修改了。绝对的对修改关闭是不可能的。无论模块多么的“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须猜测出最有可能发现的变化种类，然后构造抽象来隔离那些变化。

• 但是我们很难预先猜测，但我们却可以在发生小变化时，就及早去想办法应对发生更大变化的可能。也就是说，等到变化发生时立即采取行动。

• 在我们最初写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。

  • 比如，写一个加法程序，在一个client类中就能完成，此时变化还没有发生。然后要在此基础上加一个减法功能，你发现，增加功能需要修改原来这个类，这就违背了今天讲到的”开放-封闭原则“，于是你就该考虑重构程序，增加一个抽象的运算类，通过一些面向对象的手段，如继承，多态等来隔离具体加法、减法与client的耦合，需求依然可以满足，还能应对变化。这时再要增加乘除法功能，就不需要再去更改client以及加法减法的类了，而是增加乘法和除法子类就可以。面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。这就是“开放-封闭原则”的精神所在。

  ---

• “开放-封闭原则”是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分作出抽象，然而，对于应用程序中的每个部分都刻意进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

4.依赖倒转原则

• 依赖倒转原则：抽象不应该依赖细节，细节应该依赖抽象。说白了，就是要针对接口编程，不要对实现编程。
  • 如果把PC电脑理解成是大的软件系统，无论主板、CPU、内存、硬盘都是在针对接口设计的，如果针对实现来设计，内存就要对应到具体的某个品牌的主板，那就会出现换内存需要把主板也换了的尴尬。所以说，PC电脑硬件的发展，和面对对象思想发展是完全类似的。这也说明，世间万物都是遵循某种类似的规律，谁先把握了这种规律，谁就最早成为了强者。

---

• 依赖倒转原则：
  • A：高层模块不应该依赖低层模块。两个都应该依赖抽象。
  • B：抽象不应该依赖细节，细节应该依赖抽象。
• 为什么要叫倒转？
  • 面向过程开发时，为了使得常用代码可以服用，一般都会把这些常用代码写成许许多多函数的程序库，这样我们在做新项目的时，去调用这些底层的函数就可以了。比如我们做的项目大多要访问数据库，所以我们就把访问数据库的代码写成了函数，每次做新项目时就去调用这些函数。这就是高层模块依赖低层模块。
  • 同时问题也出在这里，我们要做新项目时，发现业务逻辑的高层模块都是一样的，但客户却希望使用不同的数据库或存储信息方式，这时就出现麻烦了。我们希望能再次利用这些高层模块，但高层模块都是与低层的访问数据库绑定在一起的，没有办法复用这些高层模块，这就非常糟糕了。而如果不管高层模块还是低层模块，它们都依赖于抽象，具体一点就是接口或抽象类，只要接口是稳定的，那么任何一个更改都不用担心其它受到的影响，这就使得无论高层模块还是低层模块都可以很容易地被复用。这才是最好的办法。
  • 为什么依赖了抽象的接口或抽象类，就不怕更改呢？这里引出以下，里氏代换原则。

4.1 里氏代换原则

• 里氏代换原则：子类型必须能够替换掉它们的父类型。
  • 一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件设计里面，把父类都替换成它的子类，程序的行为没有变化。

---

• 正是因为有了这个原则，使得继承复用成为了可能，只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能在父类的基础上增加新的行为。

动物 animal = new 猫();
animal.吃();
animal.喝();
animal.跑();
animal.跳();

• 正是由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。

---

• 再回过头来看依赖倒转原则，高层模块不应该依赖底层模块，两个都应该依赖抽象。
  

• 依赖倒转其实可以说是面向对象设计的标志，用哪种语言来编写不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面对对象设计，反之那就是过程化的设计。

5.迪米特法则

• 迪米特法则：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互左右。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
• 迪米特法则，也叫最少知识原则。
• 迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限。也就是说，一个类包装好自己的private状态，不需要让别的类知道的字段或行为就不要公开。
• 迪米特法则其根本思想，是强调了类之间的松耦合。类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。