深入浅出精讲面向对象设计七大原则，彻底领悟设计背后思想

欢迎阅读

对面向对象设计原则的学习能够提高大家的系统设计能力和代码编写质量。本文内容丰富易懂，对每一个面向对象设计原则都会举出具体的例子来进行讲解。在文章最后会对所有的面向对象设计原则进行总结。另外，本篇文章有配套的讲解视频（如果不想看文字就去看视频叭），请点击这里观看（哔哩哔哩-小勾狗有什么坏心眼呢-bili_88094125658）。欢迎大家阅读和观看~希望通过这篇文章的分享能够使得大家在今后利用面向对象语言编写代码时给大家带来一些帮助。

一、面向对象设计原则提出背景

对于我们后端来说，平时大部分时间都在使用面向对象语言来设计软件系统。对于面向对象软件系统的设计而言，在支持可维护性的同时，提高系统的可复用性是一个至关重要的问题，如何同时提高一个软件系统的可维护性和可复用性是面向对象设计需要解决的核心问题之一。像我们平时接触的23种设计模式就是以面向对象七大原则为基础进行设计的。所以对面向对象设计的七大原则的学习有助于提高我们的设计水平，使我们设计的软件系统有较高的可维护性和可复用性。今天呢，我会通过具体案例，深入浅出精讲面向对象设计七大原则，让大家彻底领悟设计背后的思想。

二、面向对象设计七大原则总览

这张表展示了今天会分享到的七大原则。下面我会结合具体的例子来一一分享各个原则。

设计原则名称	设计原则简介
单一职责原则(Single Responsibility Principle, SRP)	类的职责要单一，不能将太多的职责放在一个类中
开闭原则(Open-Closed Principle, OCP)	软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能
里氏代换原则(Liskov Substitution Principle, LSP)	在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象
依赖倒转原则(Dependency Inversion Principle, DIP)	要针对抽象层编程，而不要针对具体类编程
接口隔离原则(Interface Segregation Principle, ISP)	使用多个专门的接口来取代一个统一的接口
合成复用原则(Composite Reuse Principle, CRP)	在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系
迪米特法则(Law of Demeter, LoD)	一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互

三、单一职责原则（SRP）

3.1定义：

首先来看第一个原则，单一职责原则。单一职责原则有两种定义方式。
第一种定义是一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。（Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class.）
第二种定义是就一个类而言，应该仅有一个引起它变化的原因。（There should never be more than one reason for a class to change.）

3.2分析：

下面我们做一个具体分析。类的职责主要包括两个方面：数据职责和行为职责，数据职责通过其属性来体现，而行为职责通过其方法来体现。显而易见，一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性越小，而且如果一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。

3.3举例：

下面通过举例Java的C/S系统的“登录功能”来说明单一职责原则。在图中，登录类中的init方法是初始化方法、display是显示方法、validate是数据验证方法、getConnection是链接数据库的方法、findUser是通过数据库校验用户名和密码的方法、main方法是整个系统运行的方法。现在我们来看看他是不是符合单一职责原则。单一职责原则是一个类应该只包含一个单一的职责，而现在我们看到，Login类中其实包含了三种职责。首先是init方法、display方法和validate方法组成的展示页面的职责、然后是getConnection方法和findUser方法组成的查询数据库的职责、最后是main方法构成的运行整个系统的职责。我们说就一个类而言，应该仅有一个引起它变化的原因。如果说我们现在需要对显示做变换，那么我们需要修改display方法从而导致Login类被修改、而如果我们说现在需要修改数据库的链接方式，那么我们需要修改getConnection方法同样会导致Login类被修改，再如果说我们要修改main方法比如在运行前需要添加一下处理，那么就需要修改Login类种main方法。所以说Login类现在能引起它变化的原因有很多种。这显然不太好。

现在我们使用单一职责原则对其进行重构。对于这四个类的介绍，可以点击这里观看视频（在5分00秒处）。现在我们看到我们把Login类划分成了四个不同的类，每个类有自己的单一职责，也就是说每一个类现在引起他们变换的原因都只有一个。也就是说现在四个类是四个正交的维度，他们之间的变换是无关的。像现在这样的设计就符合了单一职责原则。这样当因为变化需要修改时，就可以只修改对应的模块而不用影响其它的模块。可以看到现在的设计，在可维护性和可复用性上都比之前的设计好很多了。比如说我们想更改getConnection方法，那么我们只会去修改UserDAO类，而其它类不会受到影响。而且引起UserDAO发生改变的原因只有一个，而不是很多个。

四、开闭原则（OCP）

4.1定义：

第二个原则，开闭原则。开闭原则定义是一个软件实体应当对扩展开放，对修改关闭。（Software entities should be open for extension, but closed for modification.）也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为。

4.2分析：

开闭原则由Bertrand Meyer于1988年提出，也就是下面图片中的这个人，旁边这两本经典的书就是他写的。开闭原则是面向对象设计中最重要的原则之一。在开闭原则的定义中，软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。在开闭原则中，抽象化是它的关键。开闭原则还可以通过一个更加具体的“对可变性封装原则”(Principle of Encapsulation of Variation, EVP)来描述，其中“对可变性封装原则”要求找到系统的可变因素并将其封装起来。

4.3举例：

现在通过举例图像界面系统中各种不同的按钮来说明开闭原则的应用。某图形界面系统提供了各种不同形状的按钮，客户端代码可针对这些按钮进行编程，用户可能会改变需求要求使用不同的按钮，原始设计方案如图所示。其中LoginForm是登录页面，包含一个button按钮，display显示方法会根据不同类型的button按钮展示不同样式的button。可以看到，每当需要变换按钮时，需要修改LoginForm中的代码，而这违反了开闭原则中所说的对修改关闭。另外，如果用户需要新的Button时，需要重新定义一个button然后修改LoginForm的代码，这对扩展很不方便。现在我们需要思考如何更改设计，来达到在不修改代码的情况下做到扩展。


现在我们使用开闭原则对其进行重构。重新构造后的结构如图所示。对于这张图的介绍，可以点击这里观看视频（在9分37秒处）。现在，当我们需要变换按钮时只需要修改配置文件就可以改变按钮的样式了，另外，如果有新的按钮，我们只需要增加一个新button类继承AbstractButton,然后修改配置文件就可以很方便地进行扩展了，可以看到我们并没有修改任何LoginForm中的代码就实现了扩展，现在的设计比之前的设计好了很多。

这里的配置文件可以让LoginForm中AbstractButton类型的button对象是配置文件中指定的类（例如图中是CircleButton）的实例。

五、里氏替换原则（LSP）

5.1定义：

第三个原则，里氏替换原则。里氏替换原则有两种方式的定义，第一个定义是：如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o2都代换成o1时，程序P的行为没有变化，那么类型S是类型T的子类型。（If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.）

第二定义是：所有引用基类（父类）的地方必须能透明地使用其子类的对象。（Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.）

其中定义一比较重要的一点是替换后行为没有发生变化，也就是说如果替换后行为发生了变化或者代码运行时出现行为/业务错误，那么这两个类就不应该是父子关系。定义二中比较重要的是透明这一个词，透明的含义是指，当基类被子类替换时，感觉不到基类被子类替换了，也就是行为不会发生变化。

5.2分析：

里氏代换原则由2008年图灵奖得主、美国第一位计算机科学女博士、麻省理工学院教授Barbara Liskov和卡内基.梅隆大学Jeannette Wing教授于1994年提出。也就是下面这两位。里氏代换原则可以通俗表述为：在软件中如果能够使用基类对象，那么一定能够使用其子类对象。把基类都替换成它的子类，程序将不会产生任何错误和异常，反过来则不成立，如果一个软件实体使用的是一个子类的话，那么它不一定能够使用基类。里氏代换原则是实现开闭原则的重要方式之一，由于使用基类对象的地方都可以使用子类对象，因此在程序中尽量使用基类类型来对对象进行定义，而在运行时再确定其子类类型，用子类对象来替换父类对象。

5.3举例：

现在通过举例对数据进行加密来说明里氏替换原则的应用。（这里举例比较复杂，建议观看视频（在13分57秒处）。）如图所示，某系统现在需要对重要数据，如用户密码，进行加密处理，在数据操作类DataOperator中需要调用加密类中定义的加密算法encrypt，系统提供了两个不同的加密类，CipherA和CipherB，它们实现不同的加密方法，在DataOperator中可以选择其中一个实现加密操作。现在考虑一个问题，如果需要更换一个加密算法类或者增加并使用一个新的加密算法类，如将CipherA改为CipherB（Client中的main方法需要修改为new CipherB，setCipherB，）或添加一个新的加密算法CipherC（DataOperator中的encrypt方法需要添加ifelse、DataOperator类还要添加一个CipherC、main方法也需要修改），则需要修改客户类Client和数据操作类DataOperator的源代码，这违背了开闭原则。

Client中的main方法：

DataOperator中的setCipherA方法：

DataOperator中的encrypt方法：

现在使用里氏代换原则对其进行重构，使得系统可以灵活扩展，符合开闭原则。重构后的结构如图所示，当需要修改加密算法时，可以直接需改配置文件；如果需要扩展加密算法，可以添加新的加密算法继承CipherA类，然后修改Config配置文件就行，保证了对修改关闭对扩展开放。可以看到通过里氏代换原则确保了开闭原则。从而提高了系统的可维护性和可复用性。

Client中的main方法：

另外，里氏替换原则还可以用来判别两个类是否应该为父子关系。下面看某公司给员工计算报酬的例子。其中{A}代表是一个抽象类。Employee是员工类，它是领月薪员工和领时薪员工的父类，Timecard是用来记录时薪员工的小时数。Employee中的抽象方法calcPay方法用来计算工资，由各个子类负责具体实现。

现在考虑如果要增加一个VolunteerEmployee志愿者员工类继承至Employee类，即这类员工没有薪水，那么calcPay该怎么实现
第一种方法，return 0：

第一种方法返回return 0,但是这样没有意义，因为如果在其它地方有一个转账方法，那么它会给志愿者转账0元，没有实际意义，志愿者打开手机银行一看给我转账0元是什么意思？

第二种方法，抛异常：

第二种方法抛异常。如果抛异常的话要么异常必须被捕获，要么调用者说明，因此，在一个派生类上的约束已经影响到了基类用户。

另外如果使用第二种方法，那原来的计算所有员工工资的代码会这样变动：
原来的代码：

变动后的代码：
使用try catch语句

或者
使用instaceof判断是哪个类型，但这样更糟糕，因为原来基于Employee基类的代码，现在必须要明确引用它的一个子类VolunteerEmployee

但不管哪样变动，都影响到了其它地方。其根源在于违背了里氏替换原则，因为VolunteerEmployee不能和Employee是父子关系。如果是父子关系会违背里氏替换原则，VolunteerEmployee不能透明地替代Employee。只要当调用一个派生类上的方法时造成了非法使用，就会违反里氏替换原则；如果使用了一个退化的派生类的方法（什么也没实现），也是违反里氏替换原则。此时说明该方法对派生类是无意义的。继承应该是关于行为的，而不是志愿者员工从直觉上判断就是员工类，而是从行为上来判断是否属于员工类。很明显这里的员工类是计算薪水的员工，而志愿者员工不计算薪水，所以志愿者员工不应该继承员工类。通过里氏替换原则可以帮助我们来判断两个类是否应该用继承关系。

六、依赖倒转原则（DIP）

6.1定义：

第四个原则，依赖倒转原则。依赖倒转原则有两种方式的定义。

第一种定义是：高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。（High level modules should not depend upon low level modules, both should depend upon abstractions. Abstractions should not depend upon details, details should depend upon abstractions.）

第二种定义是：要针对接口编程，不要针对实现编程。（Program to an interface, not an implementation.）

6.2分析：

依赖倒转原则是Robert C. Martin在1996年为《C++ Reporter》所写的专栏Engineering Notebook的第三篇，后来加入到他在2002年出版的经典著作《Agile Software Development, Principles, Patterns, and Practices》中。也就是下面这个人和他写的经典书籍。简单来说，依赖倒转原则就是指：代码要依赖于抽象的类，而不要依赖于具体的类；要针对接口或抽象类编程，而不是针对具体类编程。依赖倒转原则要求客户端依赖于抽象耦合，以抽象方式耦合是依赖倒转原则的关键。

6.3举例：

现在通过举例来说明依赖倒置原则的应用。如图中所示，现在代码一共有三层，高层模块Policy layer是策略层，中层模块Mechanism Layer是机制层，它对策略层进一步实现，底层模块Utility Layer是工具层，提供一些工具层的东西给中层模块使用。可以看到，高层调用了中层然后中层又调用了底层，越往下相对于上一层实现的越具体（上一层相当于抽象，下一层相当于具体，抽象依赖于具体）。这样的设计看起来似乎是正确的，但实际上是不好的。因为高层模块Policy layer对下面的两个层的改动都很敏感，中层模块对底层模块的改动很敏感。如果底层模块有改动，那么中层模块可能也会随之改动从而可能导致高层也会改动。

现在我们使用依赖倒置原则对其进行重构。重新构造后的结构如图所示。我们在每一层添加抽象化的接口，使下一层实现这个接口。这样当下一层发生改变时，因为上一层和下一层中间的接口没有发生改变所以不会影响到上一层，上一层只依赖于抽象的接口而不是下一层具体的实现。这样就降低了模块间的耦合，提高了系统的可维护性和可复用性。

七、接口隔离原则（ISP）

7.1定义：

第五个原则，接口隔离原则。接口隔离原则有两种方式的定义。

第一种定义是：客户端不应该依赖那些它不需要的接口。（Clients should not be forced to depend upon interfaces that they do not use.）

第二种定义是：一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法。（Once an interface has gotten too ‘fat’ it needs to be split into smaller and more specific interfaces so that any clients of the interface will only know about the methods that pertain to them.）

7.2分析：

接口隔离原则是指使用多个专门的接口，而不使用单一的总接口。每一个接口应该承担一种相对独立的角色，不多不少，不干不该干的事，该干的事都要干。使用接口隔离原则拆分接口时，首先必须满足单一职责原则，将一组相关的操作定义在一个接口中，且在满足高内聚的前提下，接口中的方法越少越好。可以在进行系统设计时采用定制服务的方式，即为不同的客户端提供宽窄不同的接口，只提供用户需要的行为，而隐藏用户不需要的行为。

7.3举例：

现在通过客户系统来说明接口隔离原则的应用。如图展示了一个拥有多个客户类的系统，在系统中定义了一个巨大的接口（胖接口）AbstractService来服务所有的客户类。可以看到对于ClienA类，AbstractService在提供operatorA方法的同时还提供了它不需要的operatorB和operatorC方法，对于ClienB类和ClienC类均是如此。显而易见，这并不合理。因为一是接口的实现类庞大，实现类中需要实现接口中的所有方法，灵活性较差，如果某些方法不实现而是大量空方法，将导致系统中产生很多无用的代码，影响代码的质量。另外由于客户端针对大接口编程，将在一定程度上破坏程序的封装性，客户端看到了不应该看到的方法，没有为客户端定制接口。这样的设计结构违背了接口隔离原则。

现在我们使用接口隔离原则对其进行重构。可以看到我们将AbstractService进行了分割，分割成了多个细小的接口。对于每一个客户类，只需要依赖它需要的接口就行了。如此以来不同的客户类使用不同的接口，只提供客户类需要的行为，隐藏了客户类不需要的行为。这样的设计显然是合理的。

八、迪米特法则（LOD）

8.1定义：

接下来要介绍的是迪米特法则(Law of Demeter, LoD)又称为最少知识原则(Least Knowledge Principle, LKP)，它有多种定义方法，其中几种典型定义如下。
第一种定义是不要和“陌生人”说话（Don’t talk to strangers.）。
第二种定义是只与你的直接朋友通信（Talk only to your immediate friends.）。
第三种定义是每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位（Each unit should have only limited knowledge about other units: only units “closely” related to the current unit.）。

8.2分析：

简单来说，迪米特法则就是指一个软件实体应当尽可能少的与其他实体发生相互作用。这样，当一个模块修改时，就会尽量少的影响其他的模块，扩展会相对容易，这是对软件实体之间通信的限制，它要求限制软件实体之间通信的宽度和深度。

在迪米特法则中，对于一个对象，其朋友包括以下几类：
(1) 当前对象本身(this)；
(2) 以参数形式传入到当前对象方法中的对象；
(3) 当前对象的成员对象；
(4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友；
(5) 当前对象所创建的对象。任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”，否则就是“陌生人”。

在狭义的迪米特法则中，如果两个类之间不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中的一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。下面这张图的介绍请观看视频（在33分48秒处）

迪米特法则的主要用途在于控制信息的过载：
1.在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及；
2.在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限；
3.在类的设计上，只要有可能，一个类型应当设计成不变类；
4.在对其他类的引用上，一个对象对其他对象的引用应当降到最低。

8.3举例：

现在通过举例来说明迪米特法则的应用。如图展示了某系统界面类(如Form1、Form2等类)与数据访问类(如DAO1、DAO2等类)之间的调用，可以从图中看到它们的调用关系较为复杂。迪米特法则强调不要有太多的紧耦合而是应该是采用松耦合，一个软件实体应当尽可能少的与其他实体发生相互作用。可以看到，Form3与DAO2-4这三个DAO都有关联，其中有一个发生变换都会影响到Form3。另外DAO2发生改变除了会影响Form3还会影响Form4,Form5,所以下面的设计是一个不太好的设计。

现在我们使用迪米特法则对其进行重构。重构的结果如图所示。可以看到，我们在Form和DAO的中间添加了一个中间层Controller,这样就降低了系统的耦合。Form通过中间的Controller与DAO发生间接的通信。这样当DAO发生改变时就不会影响到Form,达到了Form尽可能少的与其他实体发生相互作用的目的。

九、合成复用口原则（CRP）

9.1定义：

最后一个原则，合成复用原则。合成复用的定义是尽量使用对象组合，而不是继承来达到复用的目的。（Favor composition of objects over inheritance as a reuse mechanism.）

9.2分析：

合成复用原则就是指在一个新的对象里通过关联关系（包括组合关系和聚合关系）来使用一些已有的对象，使之成为新对象的一部分；新对象通过委派调用已有对象的方法达到复用其已有功能的目的。简言之：要尽量使用组合/聚合关系，少用继承。因为通过继承来复用，虽然实现简单。但破坏系统的封装性；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性；只能在有限的环境中使用。（“白箱”复用 ）而通过组合/聚合来复用，可以使耦合度相对较低，选择性地调用成员对象的操作；可以在运行时动态进行。（“黑箱”复用 ）

9.3举例：

现在举例来说明接口隔离原则的应用。某教学管理系统部分数据库访问类设计如图所示，可以看到StudentDAO和TeachearDAO通过继承来复用DBUtil中的getConnection方法来链接数据库，首先可以发现DBUtil和Student/TeachearDAO不是is-a的关系，也就是从语义来说不应该继承关系。另外，如果需要更换数据库连接方式，如原来采用JDBC连接数据库，现在采用数据库连接池连接，则需要修改DBUtil类源代码。如果StudentDAO采用JDBC连接，但是TeacherDAO采用连接池连接，则需要增加一个新的DBUtil类，并修改StudentDAO或TeacherDAO的源代码，使之继承新的数据库连接类，这将违背开闭原则，系统扩展性较差。

现在我们使用合成复用原则对其进行重构。重构的结果如图所示。可以看到这一次我们采用了聚合的方式来复用DBUtil。这样一来当我们需要换数据库链接方法时，可以创建一个新类NewDBUtil来继承DBUtil从而在满足开闭原则的前提下，对功能进行扩展。可以看到新的设计结构提高了系统的可维护性和可复用性。

十、面向对象设计原则总结

七大原则本质上指导了两件事情，第一件事情是一个类该如何设计，第二件事情是两个类关系该如何设计。对于一个类该如何设计主要遵循单一职责原则，即类的职责要单一，不能将太多的职责放在一个类中，类的变化点要尽可能少和开闭原则，即软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能。这两个原则使得一个类满足高内聚。对于2个类关系该如何设计，从策略上来讲，最鼓励我们去遵循的首先是迪米特法则，即两个类尽量不要发生关系，要尽量少的去发生关系；如果非要发生关系，鼓励遵循依赖倒置原则，要依赖抽象，和抽象发生关系而不是具体的类发生关系，即要针对抽象层编程，而不要针对具体类编程；接着就是，若发生依赖关系，要注意接口隔离原则，即，使用多个专门的接口来取代一个统一的接口，要依赖也仅仅依赖自己需要的服务；如果现在有复用的需要，应该优先使用关联关系而不是继承，即遵循合成复用原则；如果关联关系满足不了要求，非要用继承，那么此时就应该遵循里氏替换原则，即所有引用基类（父类）的地方必须能透明地使用其子类的对象。迪米特法则、依赖倒置原则、接口最小隔离原则、合成复用原则和里氏替换原则使得类之间满足松耦合。

可见遵循面向对象设计的七大原则可以使我们的系统实现高内聚松耦合并且能够提高系统的可维护性和可复用性，希望通过今天的分享能够使得大家在今后利用面向对象语言编写代码时给大家带来一些帮助，使得在设计系统时更合理，编写代码时质量更高，以上就是今天给大家分享的全部内容，感谢大家的阅读。