面向对象设计的五项基本原则

面向对象设计（OOD）是面向对象编程（OOP）必不可少的一个环节，只有好的设计，才能保障程序的质量。

面向对象设计的主要任务就是类的设计，不少面向对象（OO）的先驱和前辈已经提出了很多关于类的设计原则，用于指导 OOP，其中就包括类设计的五项基本原则。

1.单一职责原则（SRP: Single Resposibility Principle）

专注是一个人的优良品质，同样，单一职责也是一个类的优良设计。单一职责的核心思想：一个类只做好一件事情。

单一职责原则可以看作是高内聚、低耦合在面向对象原则上的引申。类的职责过多，容易导致类间职责依赖，提高耦合度，降低内聚性。通常意义下的单一职责，指的是类只有一种单一功能，不要为类设计过多的功能，交杂不清的功能会使代码杂乱，提高程序开发的难度和系统出错的概率，降低系统的可维护性。

要举个体现单一职责原则的最常见的例子无疑就是STL中的迭代器的设计。有些人觉得容器跟迭代器的分离是不好的设计，觉得增加了复杂度，不如直接把迭代器放在容器里更为简洁。不过很多人还是不这样认为，因为类的数量越多并不代表就越复杂，另外迭代器如果放到容器里面，就会暴露容器的一些内部结构，不太符合封装的思想。还有就是可扩展性的问题，因为对容器的访问遍历会有多种需求，如果把迭代器隔离开来你可以不修改容器类，再定义些特制的迭代器就行了，这样不管有什么奇怪的需求只要写个对应的迭代器出来就行了。

2.开放封闭原则（OCP: Open Closed Principle）

开闭原则指的是开放封闭原则，即对扩展开放，对修改封闭。

所谓修改封闭，就是之前设计好的类，不要去修改。比如删除掉一个成员函数、改变成员函数的形参列表或更改数据成员类型等。实现对修改封闭，关键在于抽象化。对一个事物抽象化，实质上是对一个事物进行概括、归纳、总结，将其本质特征抽象地用一个类来表示，这样类才会相对稳定，无需更改。

所谓扩展开放，就是在不改变已存在的类的前提下可以添加很多功能。一般是通过继承和多态来实现，如此一来，可以保持父类的原样，只需在子类中添加些所需的新功能。

“需求总是变化的”，如果遵循开放封闭原则，合理设计就能封闭变化，使类能够灵活的扩展所需的功能。

3.里氏替换原则（LSP: Liskov Substituion Principle）

Liskov 替换原则指的是：子类可以替换父类并出现在父类能够出现的任何地方。这个原则是 Liskov 于1987年提出，它同样可以从 Bertrand Meyer的 DBC（Design by Contract，按契约设计）的概念推出。

C++ 语言机制将类的抽象与多态建立在继承的基础上，其实现的方法是面向接口编程：通过提取纯虚类（Abstract Class），将公共部分抽象为基类接口或由子类重写覆盖基类方法来达到多态的目的。Liskov 替换原则的作用就是为了保证继承复用的可靠。

下面来举个违反替换原则的特殊例子：
正方形与长方形的问题也是属于“圆不是椭圆”这类问题。我们知道正方形是一个特殊的长方形，所以可以设计两个类，正方形类继承自长方形类。长方形类有两个成员变量，分别表示长和宽，有个计算面积的成员函数。假如计算面积的方法是virtual的，这样能实现多态。在先设定长和宽后再调用计算面积的方法。我们知道正方形是长和宽相等的，如果设定长和宽的时候不是一样的，然后调用了正方形的面积计算公式，这样肯定就错了。你可能会问咋这么扯蛋啊，为啥把长和宽设成不一样啊。很多设计思想和方法是一来为了方便，二来为了让用户少犯错误，就是不管你怎么使用都不会出错，要出错应该是在编译时出错，放置运行时出错。如果出现上面说的情况编译器是没法让你知道出错了的。

所以一个正方形类继承自长方形类的设计是不好的（注意的一点是你违反了 Liskov 替换原则并不是说就写的代码就会出错，只是说设计不太合理。实际上你这样设计代码没准可以正常的跑得很好呢，如果没有出现一些特殊情况可能是一点 bug 也没有，只不过设计不合理为导致一些安全隐患而已）。

4.依赖倒置原则（DIP: Dependecy Inversion Principle）

其核心思想是：依赖于抽象。具体而言就是高层模块不依赖于底层模块，二者都依赖于抽象；抽象不依赖于具体，具体依赖于抽象。依赖倒置原则是对传统过程性设计方法的“倒转”，是高层次模块复用及其可维护性的有效规范。

依赖一定存在于类与类、模块与模块之间。类与类之间产生依赖时，依赖倒置原则的理解可以描述如下：依赖就是刚开始时具体细节间互相依赖，我们将实现的细节变成抽象类，降低类间耦合度。然后有了抽象类，继承自它的实现类也要依赖它。那倒置两字咋理解呢? 一般情况我们是先关注细节，然后根据细节抽象出来一些概括的方法，所以按常理一般是抽象要依赖于细节的，而现在是是倒过来了,确定一个抽象类后，那些细节的实现得以抽象出来的方法为基准，变成了细节依赖于抽象了，不然你要继承了一个抽象类，你不完全实现它的方法的话可不让你实例化对象的啊。

当两个模块之间存在紧密的耦合关系时，最好的方法就是分离接口和实现：在依赖之间定义一个抽象的接口，供高层模块调用，底层模块实现接口的定义，从而有效控制耦合关系，达到依赖于抽象的设计目的。

依赖于抽象就是不对实现编程，而对接口编程。依赖于抽象是一个通用原则，而有些时候依赖于细节是在所难免的，我们需要根据具体情况在在抽象与具体之间进行取舍。

5.接口分离原则（ISP: Interface Segregation Principle）

该原则的核心思想是：使用多个小的专门的接口，而不要使用一个大的总接口。具体而言，接口应该是内聚的，应该避免“胖”接口。一个类对另一个类的依赖应该建立在最小的接口上，而不要强迫依赖不同的方法，这是一种接口污染。

其实简单点的讲与前面说的单一职责类似，这里的接口不是函数接口，而是一个类。C#中的有专门的接口interface，和类区分开来，而且C#中不像C++支持类的多继承，只支持接口的多继承，所以这里可以把接口理解成功能更小更特殊的类，一个接口可能就只要那么几个很少的方法就OK了。

接口分离手段主要有以下两种方式：
（1）利用委托分离接口；
（2）利用多重继承分离接口。

6.小结

概括地讲，面向对象设计原则仍然是面向对象思想的体现。例如，

• 单一职责原则要求类只负责一件事情；
• 接口分离原则，让客户只关心他们所需的接口。单一职责原则与接口分离原都体现了内聚的思想；
• 开放封闭原则，要求类不作修改而能够扩展功能，体现了类的封装与继承；
• Liskov 替换原则，要求派生类要能够替换基类，是对类继承的规范；
• 依赖倒置原则，要求类依赖于抽象，而不是实现，是抽象思想的体现。

上面五条面向对象设计原则，可以帮助我们设计出代码易复用、功能易扩展、维护易进行的程序，需要我们在实践中遵守。

---

参考文献

类设计的5个基本原则
李健.编写高质量代码：改善C++程序的150个建议[M].第一版.北京：机械工业出版社，2012.1:316-317