面向对象设计原则_重温设计模式系列（三）面向对象设计原则

背景

面向对象基础知识，只是给了我们一个概念，如何更好的设计出良好的面向对象代码，需要有设计原则作为支持。设计原则是核心指导思想，在这些原则的基础上，经过不断的实践，抽象，提炼逐步产生了针对特定问题的设计模式。因此，学好设计模式的基础是掌握基本的设计原则。本文将介绍面向对象常用的设计原则。(某些原则，也可以用在系统级，模块级等类型的设计中应用)

1、代码抽象三原则

1.1 DRY原则(Don't repeat yourself)

意思是：不要重复自己。它的涵义是，系统的每一个功能都应该有唯一的实现。也就是说，如果多次遇到相同的问题，就需要抽象出一个通用的解决方案，不要重复开发相同的功能。

用代码举例：如果两个地方需要发送短信的功能，第一个功能是发送提醒短信，第二个是发送验证码短信。则需要把发送短信的公用代码进行提炼。

1.2 YAGNI原则( You aren't gonna need it)

意思是：你不会需要它。出自极限编程的原则，指除了核心功能外，其它功能一概不要部署。背后的指导思想是尽快的让代码运行起来。简单理解是尽量避免不必要的代码，少就是多。比如：过多的日志打印，过多逻辑检查，过多的异常处理等，如果能简化则简化。

1.3Rule Of Three原则

Rule of three 称为"三次原则"，指的是当某个功能第三次出现时，才进行"抽象化"。它的含义是：当第一次用到某个功能时，写一个特定的解决方法；第二次又用到的时候，拷贝上一次的代码；第三次出现的时候，才着手"抽象化"，写出通用的解决方法。

1.4 三原则之间的关系

DRY强调对通用问题的抽象，YAGNI强调快速和简单。Rule Of Three相当于对前两个原则做了一个折衷，提出了应用原则的度量。三原则的折中，有以下几个好处。

(1)省事，避免过度设计：如果只有一个地方用，就没必要过度抽象，避免过度设计。

(2)容易发现模式：问题出现的场景多，容易找到通用的部分，方便进行抽象，进而找到模式。

2、GRASP原则

GRASP(General Responsibility Assignment Software Patterns)，中文名称：“通用职责分配软件模式”，核心是自己干自己能干的事，自己只干自己的 事，也就是职责的分配和实现高内聚。用来解决面向对象设计的一些问题。GRASP一共包括9种模式，给出了最基本的面向对象指导原则，比如：如何决定一个系统有多少对象，每个对象都包括什么职责。

2.1 Infomation Expert(信息专家)

设计类时，如果一个类有完成某个职责的所有信息，则应该把该职责分配给该类。此时，该类相当于该职责的信息专家。

例如： 常见的网上商店的购物车(ShopCar)，需要让每种商品(SKU)只在购物车内出现一次，购买相同商品，只需要更新商品的数量即可。如下图：

针对这个问题需要权衡的是，比较商品是否相同的方法放到哪个类里来实现呢？分析业务得知需要根据商品的编号(SKUID)来唯一区分商品，而商品编号是唯一存在于商品类的，所以根据信息专家模式，应该把比较商品是否相同的方法放在商品类里。

2.2 Creator(创造者)

用于判断对象的初始化由哪个类发起，用于确定正确的依赖关系。实际应用中，符合下列任一条件的时候，都应该由类 A 来创建类 B，这时 A 是 B 的创建者：

a、A 是 B 的聚合

b、A 是 B 的容器

c、A 持有初始化 B 的信息(数据)

d、A 记录 B 的实例

e、A 频繁使用 B

例如：因为订单(Order)是商品(SKU)的容器，所以应该由订单来创建商品。如下图：

这里因为订单是商品的容器，也只有订单持有初始化商品的信息，所以这个耦合关系是正确的且没有办法避免的，所以由订单来创建商品。

2.3 Low coupling(低耦合)

耦合是指两个类之间的依赖程度。低耦合说明两个类之间的依赖程度低。好的耦合是低耦合，有以下好处：

(1)低耦合降低了因为一个类的变化，影响其他类的范围。

(2)使类之间的关系简单，更容易理解。

耦合的场景

a、A 是 B 的属性

b、A 调用 B 的实例的方法

c、A 的方法中引用的 B，例如 B 是 A 方法的返回值或参数。

d、A 是 B 的子类，或者 A 实现 B

例如：Creator 模式的例子里，实际业务中需要另一个出货人来清点订单(Order)上的商品(SKU)，并计算出商品的总价，但是由于订单和商品之间的耦合已经存在了，那么把这个职责分配给订单更合适，这样可以降低耦合，以便降低系统的复杂性。如下图：

这里我们在订单类里增加了一个 TotalPrice() 方法来执行计算总价的职责，没有增加不必要的耦合。

2.4 High cohesion(高内聚)

内聚是指类内部职责的紧密程度，高内聚的类是设计良好的类，具备良好的隔离性，当内部变化了，只要接口不改变，不影响其他部分。

例如：一个订单数据存取类(OrderDAO)，订单即可以保存为 Excel 模式，也可以保存到数据库中；那么，不同的职责最好由不同的类来实现，这样才是高内聚的设计，如下图：

这里我们把两种不同的数据存储功能分别放在了两个类里来实现，这样如果未来保存到 Excel 的功能发生错误，那么就去检查 OrderDAOExcel 类就可以了，这样也使系统更模块化，方便划分任务，比如这两个类就可以分配到不同的人同时进行开发，这样也提高了团队协作和开发进度。

2.5 Controller(控制器)

用于接收和处理系统事件的职责，一般配置给可以代表整个系统的类，一般成功XXController。

有如下原则：

a、系统事件的接收与处理通常由一个高级类来代替。

b、一个子系统会有很多控制类，分别处理不同的事务。

在MVC架构中，对应的是C。

2.6 Polymorphism(多态)

面向对象的三大特征一下，指一个接口可以有不同的实现，用于提高系统的灵活性和扩展性，写出高内聚，低耦合的代码。

例如：我们想设计一个绘画程序，要支持可以画不同类型的图形，我们定义一个抽象类 Shape，矩形(Rectangle)、圆形(Round)分别继承这个抽象类，并重写(override)Shape 类里的Draw() 方法，这样我们就可以使用同样的接口(Shape抽象类)绘制出不同的图形，如下图：

这样的设计更符合高内聚和低耦合原则，虽然后来我们又增加了一个菱形(Diamond)类，对整个系统结构也没有任何影响，只要增加一个继承 Shape 类就行了。

2.7 Pure Fabrication(纯虚构)

这里的纯虚构跟我们常说说的纯虚构函数意思相近。高内聚低耦合，是系统设计的终极目标，但是内聚和耦合永远都是矛盾对立的。高内聚以为这拆分出更多数量的类，但是对象之间需要协作来完成任务，这又造成了高耦合，反过来依然。该如何解决这个矛盾呢？这个时候就需要纯虚构模式，由一个纯虚构的类来协调内聚和耦合，可以在一定程度上解决上述问题。

例如：上面多态模式的例子，如果我们的绘图程序需要支持不同的系统，那么因为不同系统的API结构不同，绘图功能也需要不同的实现方式，那么该如何设计更合适呢？如下图：

这里我们可以看到，因为增加了纯虚构类AbstractShape，不论是哪个系统都可以通过AbstractShape 类来绘制图形，我们即没有降低原来的内聚性，也没有增加过多的耦合，可谓鱼肉和熊掌兼得。

2.8 Indirection(间接)

用于隔离或组合两个类之间的交互，避免两个或多个事物之间直接耦合，比如用户类和商品类，两者的职责不同，如果之间进行直接调用，会形成强耦合(多对多关系)，则可以增加一个中间者，实现对调用用户类和商品类的聚合处理。

2.9 Protected Variations(防止变异)

如何设计对象、系统和子系统，使其内部的变化或者不稳定因素不会对其他元素产生不良影响？

预先识别不稳定的因素，抽象为接口，针对接口编程，隔离变化，如果未来发生变化，可以通过接口扩展新功能。例如：订单支付中的支付方式是不稳定的，刚开始有网银，快捷，之后又有了微信，支付宝。在设计时可以抽象出支付接口，当增加微信时，增加微信实现即可。

3、SOLID原则

3.1 单一职责原则(Single Responsibility Principle - SRP)

一个类只有一个引起变化的原因。如果一个类有多个引起变化的原因，当其中一个变化时会影响到其他代码。这样代码的内聚性不好，会导致维护性变差，复用性降低。

用于指导对类的设计，只有一个引起变化的原因，单一职责，设计出高内聚的类(或方法等元素)。

3.2 开放封闭原则(Open Closed Principle - OCP)

对于软件实体应该对扩展开放，对修改关闭。对扩展开放，是指当有新需求或需求变化时，可以仅对代码进行扩展，就可以适应新的需求。对修改关闭是指，类或方法一旦设计完成，就不需要对其进行修改。

实现开闭原则的基础时，找到变化，封装变化。

用于指导可扩展的设计。

3.3 里氏替换原则(Liskov Substitution Principle - LSP)

一个软件实体如果使用的是基类的话， 那么也一定适用于其子类， 而且它根本觉察不错使用的是基类对象还是子类对象；反过来的代换这是不成立的，

用于指导继承体系的设计。子类出现的子类，父类可以替换，在子类设计时可以扩展父类的功能，但不能改变父类原有的功能。

3.4 最少知识原则(Least Knowledge Principle - LKP)

最少知识原则又叫迪米特法则。一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。也就是说一个软件实体应当尽可能少的与其他实体发生相互作用。当一个模块修改时，尽量少的影响其他的模块，容易扩展，这是对软件实体之间通信的限制，要求限制软件实体之间通信的宽度和深度。

用于指导类之间的关系(通信)设计。

3.5 接口隔离原则(Interface Segregation Principle - ISP)

接口隔离原则的含义是：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。

用于指导接口的设计，对接口进行约束。

(1)接口尽量单一，但要适度，避免过多的接口类定义。

(2)实现类只实现需要的接口即可，当一个类实现多个接口时，调用时在具体场景只使用单一接口即可，把不必要的隐藏起来。这样依赖关系是最小的。有利于控制变化。

3.6 依赖倒置原则(Dependence Inversion Principle - DIP)

依赖倒置原则的核心思想是面向接口编程，不应该面向实现类编程。

(1)抽象不应该依赖于细节。细节应该依赖于抽象。

(2)高层不应该依赖于底层，两者都应该依赖于抽象。

用于指导抽象设计，依赖稳定的，将稳定的进行抽象。

4、其他设计原则

4.1 组合/聚合复用原则(Composition/Aggregation Reuse Principle - CARP)

在设计中，优先考虑使用组合，而不是继承。继承容易产生副作用，组合具有更好的灵活性。如：代理模式、装饰模式、适配器模式等。

4.2 无环依赖原则(Acyclic Dependencies Principle - ADP)

当 A 模块依赖于 B 模块，B 模块依赖于 C 模块，C 依赖于 A 模块，此时将出现循环依赖。在设计中应该避免这个问题，可通过引入“中介者模式”解决该问题。

4.3 共同封装原则(Common Closure Principle - CCP)

将易变的类放在同一个包里，将变化隔离出来。该原则是“开放-封闭原则”的延生。

4.4 共同重用原则(Common Reuse Principle - CRP)

如果重用了包中的一个类，那么也就相当于重用了包中的所有类，我们要尽可能减小包的大小。

4.5 好莱坞原则(Hollywood Principle - HP)

好莱坞明星的经纪人一般都很忙，他们不想被打扰，往往会说：Don't call me, I'll call you. 翻译为：不要联系我，我会联系你。对应于软件设计而言，最著名的就是“控制反转”(或称为“依赖注入”)，我们不需要在代码中主动的创建对象，而是由容器帮我们来创建并管理这些对象。

4.6 保持它简单与傻瓜(Keep it simple and stupid - KISS)

不要让系统变得复杂，界面简洁，功能实用，操作方便，要让它足够的简单，足够的傻瓜。

4.7 惯例优于配置(Convention over Configuration - COC)

尽量让惯例来减少配置，这样才能提高开发效率，尽量做到“零配置”。很多开发框架都是这样做的。

4.8 命令查询分离(Command Query Separation - CQS)

在定义接口时，要做到哪些是命令，哪些是查询，要将它们分离，而不要揉到一起。在读写分离或分布式系统中应用较多。

4.9 关注点分离(Separation of Concerns - SOC)

将一个复杂的问题分解为多个简单的问题，然后逐个解决简单的问题，那么复杂的问题就解决了。

4.10 契约式设计(Design by Contract - DBC)

模块或系统之间的交互，都是基于契约(接口或抽象)的，而不要依赖于具体实现。该原则建议我们要面向契约编程。

小结

本文介绍了常用的设计原则，基于这些原则，可以用于指导代码设计，架构评审，Code Review等。在设计原则的基础上产生了设计模式，下一篇，我们会整体介绍GOF 23种设计模式。