软件开发设计原则

软件开发设计原则

类图：

这幅图清晰地表达 了六大设计原则，但仅限于它们叫什么名字而已，它们具体是什么意
思呢？下面我将从原文、译文、理解 、应用，这四个方面分别进行阐述。
基本设计原则
1、单一职责原则（Single Responsibility Principle - SRP）

原文：There should never be more than one reason for a class to change。
译文：永远不应该有多于一个原因来改变某个类。
理解：对于一个类 而言，应该仅有一个引起它变化的原因。说白了就是，不同的类具备不同
的职责，各施其责。这就好比一 个团队，大家分工协作，互不影响，各做各的事情。
应用：当我们做系统设计时，如果发现有一个类拥 有了两种的职责，那就问自己一个问题：
可以将这个类分成两个类吗？如果真的有必要，那就分吧。千万 不要让一个类干的事情太多！

2、开放封闭原则（Open Closed Principle - OCP）

原文：Software entities like classes， modules and functions should be open for extension
but closed for modifications。
译文：软件实体，如：类、模块与函数，对于扩展应该是开放的，但对于修改应该是封闭的。
理解：简言之，对扩展开放，对修改封闭。换句话说，可以去扩展类，但不要去修改类。
应用 ：当需求有改动，要修改代码了，此时您要做的是，尽量用继承或组合的方式来扩展类
的功能，而不是直 接修改类的代码。当然，如果能够确保对整体架构不会产生任何影响，那
么也没必要搞得那么复杂了，直 接改这个类吧。

3、里氏替换原则（Liskov Substitution Principle - LSP）

原文：Functions that use pointers or references to base classes must be able to use
objects of derived classes without knowing it。
译文：使用基类的指针或引用的函数，必须是在不知情的情况下，能够使用派生类的对象。
理 解：父类能够替换子类，但子类不一定能替换父类。也就是说，在代码中可以将父类全部

替换为子类，程序不会报错，也不会在运行时出现任何异常，但反过来却不一定成立。
应用：在继承类时，务必重写（Override）父类中所有的方法，尤其需要注意父类的 protected
方法（它们往往是让您重写的），子类尽量不要暴露自己的 public 方法供外界调用。
该原则由麻省理工学院的 Barbara Liskov 女士提出，她是美国第一位获取计算机博士学位
的女性，曾经也获得过计算机图灵奖。

4、最少知识原则（Least Knowledge Principle - LKP）

原文：Only talk to you immediate friends。
译文：只与你最直接的朋友交流。
理解：尽量减少对象之间的交互，从而减小类之间的耦合。 简言之，一定要做到：低耦合，
高内聚。
应用：在做系统设计时，不要让一个类依赖于太多的 其他类，需尽量减小依赖关系，否则，
您死都不知道自己怎么死的。
该原则也称为“迪米特法则（Law of Demeter）”，由 Ian Holland 提出。这个人不太愿意和
陌生人说话，只和他走得最近的朋友们交流。

5、接口隔离原则（Interface Segregation Principle - ISP）

原文：The dependency of one class to another one should depend on the smallest
possible interface。
译文：一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口。
理解：不要对外暴露没 有实际意义的接口。也就是说，接口是给别人调用的，那就不要去为
难别人了，尽可能保证接口的实用性 吧。她好，我也好。
应用：当需要对外暴露接口时，需要再三斟酌，如果真的没有必要对外提供的，就 删了吧。
一旦您提供了，就意味着，您将来要多做一件事情，何苦要给自己找事做呢。

6、依赖倒置原则（Dependence Inversion Principle - DIP）

原文：High level modules should not depends upon low level modules。 Both should
depend upon abstractions。 Abstractions should not depend upon details。 Details should
depend upon abstractions。
译文：高层模块不应该依赖于低层模块，它们应该依赖于抽象。抽象不应 该依赖于细节，细
节应该依赖于抽象。
理解：应该面向接口编程，不应该面向实现类编程。面 向实现类编程，相当于就是论事，那
是正向依赖（正常人思维）；面向接口编程，相当于通过事物表象来 看本质，那是反向依赖，
即依赖倒置（程序员思维）。
应用：并不是说，所有的类都要有一个 对应的接口，而是说，如果有接口，那就尽量使用接
口来编程吧。
将以上六大原则的英文首字母拼在一起就是 SOLID（稳定的），所以也称之为 SOLID 原则。
只有满足了这六大原则，才能设计出稳定的软件架构！但它们毕竟只是原则，只是四人帮给我们的建议，有些时候我们还是要学会灵活应变，千万不要生搬硬套，否则只会把简单问题
复杂化， 切记！

补充设计原则

1、组合聚合复用原则（CompositionAggregation Reuse Principle - CARP）

当要扩展类的功能时，优先考虑使用组合，而不是继承。这条原则在 23 种经典设计
模式中频繁使用，如：代理模式、装饰模式、适配器模式等。可见江湖地位非常之高！

2、无环依赖原则（Acyclic Dependencies Principle - ADP）

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

3、共同封装原则（Common Closure Principle - CCP）

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

4、共同重用原则（Common Reuse Principle - CRP）

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

5、好莱坞原则（Hollywood Principle - HP）

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

其他设计原则

1、不要重复你自己（Don’t repeat yourself - DRY）

不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。

2、保持它简单与傻瓜（Keep it simple and stupid - KISS）

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

3、高内聚与低耦合（High Cohesion and Low Coupling - HCLC）

模块内部需要做到内聚度高，模块之间需要做到耦合度低。

4、惯例优于配置（Convention over Configuration - COC）

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

5、命令查询分离（Command Query Separation - CQS）

在定义接口时，要做到哪些是命令，哪些是查询，要将它们分离，而不要揉到一起。

6、关注点分离（Separation of Concerns - SOC）

将一个复杂的问题分离为多个简单的问题，然后逐个解决这些简单的问题，那么这个 复
杂的问题就解决了。难就难在如何进行分离。

7、契约式设计（Design by Contract - DBC）

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

8、你不需要它（You aren’t gonna need it - YAGNI）

不要一开始就把系统设计得非常复杂，不要陷入“过度设计”的深渊。应该让系统足够的
简单，而却又不失扩展性，这是其中的难点。
敏捷开发模式的修炼之道

关于高内聚低耦合

什么是耦合度

软件设计中通常用 耦合度和内聚度作为衡量模块独立程度的标准。划分摸块的一个准则
就是高内聚低耦合。 耦合度(Co upling)是对模块间关联程度的度量。耦合的强弱取决与模
块间接口的复杂性、调用模块的方式以 及通过界面传送数据的多少。 模块间的耦合度是指
模块之间的依赖关系，包括控制关系、调用关系、数 据传递关系。模块间联系越多，其耦合
性越强，同时表明其独立性越差。降低模块间的耦合度能减少模块 间的影响，防止对某一模
块修改所引起的“牵一发动全身”的水波效应，保证系统设计顺利进行。 内聚和耦合密切
相关，同其它模块存在强耦合关系的模块常意味这弱内聚，强内聚常意味着弱耦合。 < br>耦合度就是某模块（类）与其它模块（类）之间的关联、感知和依赖的程度，是衡量代码独
立性的 一个指标，也是软件工程设计及编码质量评价的一个标准。
耦合的强度依赖于以下几个因素：
（1）一个模块对另一个模块的调用；
（2）一个模块向另一个模块传递的数据量；
（3）一个模块施加到另一个模块的控制的多少；

（4）模块之间接口的复杂程度。
耦合按从强到弱的顺序可分为以下几种类型：
非直接耦合：两模块间没有直接关系，之间的联系完全是通过主模块的控制和调用来实现的
数据耦合：一个模块访问另一模块，彼此间通过简单数据参数来交换输入、输出信息。这里
的简单数据参数不同于控制参数、公共数据结构或外部变量。
标记耦合：如一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构
的子结构，不是简单变量。
控制耦合：一个模块通过传递开关、标志、名字等控制信息，明显的控制选择另一模块的功
能。
外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数
传递该全局变量的信息
公共耦合：一组模块都访问同一个公共数据环境。该公共数据环境可以是全局数据结构、共
享的通信区、内存的公共覆盖区等。
内容耦合：一个模块直接修改另一个模块的数据，或直接转入另一个模块内聚度是指内部各
元素之间联系的紧密程度，模块的内聚种类通常可分为7种，按其内聚度从低到高的
次序依此为：偶然内聚、逻辑内聚、瞬时内聚、过程内聚、通信内聚、顺序内聚、功能内聚。

二、为什么要低耦合

了解什么是耦合及耦合的分类后，我想大家对为什么要降低耦合度已经有一定的认识，
并且多数开发人员也大概尝尽了高耦合带来的苦头。道理很简单，耦合度很高的情况下，维
护代码时修改一个地方会牵连到很多地方，如果修改时没有理清这些耦合关系，那么带来的
后果可能会是灾难性的，特别是对于需求变化较多以及多人协作开发维护的项目，修改一个
地方会引起本来已经运行稳定的模块错误，严重时会导致恶性循环，问题永远改不完，开发
和测试都在各种问题之间奔波劳累，最后导致项目延期，用户满意度降低，成本也增加了，
这对用户和开发商影响都是很恶劣的，各种风险也就不言而喻了。
为了预防这些问题的发生，其中一个重要手段就是降低代码的耦合度。但也不可能有绝
对的零耦合，比如基于J2EE编程那就必须和JDK耦合，而且高耦合也不是一无是处，如
果在设计前期预料到某功能后期基本不用修改，那么即使高耦合了也关系不大。
但是，在还没有能力设计出基本不用修改的代码前，还得要求以低耦合为标准。那么怎
样才能最大限度地降低耦合度呢？下面介绍降低耦合度的几种方法。

三、降低耦合度的方法
1、少使用类的继承，多用接口隐藏实现的细节。 java面向对象编程引入接口除了支持多
态外， 隐藏实现细节也是其中一个目的。
2、模块的功能化分尽可能的单一，道理也很简单，功能单一的模块供其它模块调用的机会
就 少。（其实这是高内聚的一种说法，高内聚低耦合一般同时出现，为了限制篇幅，我们将
在以后的版期中 讨论）。
3、遵循一个定义只在一个地方出现。
4、少使用全局变量。
5、类属性和方法的声明少用public，多用private关键字，
6、多用设计模式，比如采用MVC的设计模式就可以降低界面与业务逻辑的耦合度。
7、尽量不用“硬编码”的方式写程序，同时也尽量避免直接用SQL语句操作数据库。
8、最后当然就是避免直接操作或调用其它模块或类（内容耦合）；如果模块间必须存在耦

合，原则上尽量使用数据耦合，少用控制耦合，
限制公共耦合的范围，避免使用内容耦合。
内聚： 故名思议，表示内部间聚集、关联的长度，那么高内聚就是指要高度的聚集和关联。

高内聚:
类与类之间的关系而定，高，意思是他们之间的关系要简单，明了，不要有很强的
关系，不然，运行起来就会出问题。一个类的运行影响到其他的类。由于高内聚具备鲁棒性，
可靠性，可重用性，可读性等优点，模块设计推荐采用高内聚。这是软件工程中的概念，是
判断设计好坏的标准，主要是面向OO的设计，主要是看类的内聚性是否高，偶合度是否
低“高内聚，低耦合”，首先要知道一个软件是由多个子程序组装而成， 而一个程序由多个
模 块(方法)构成!“高内聚，低耦合”主要是阐述的面向对象系统中，各个类需要职责分离的
思想。
每一个类完成特定的独立的功能，这个就是高内聚。耦合就是类之间的互相调用关系，
如果耦合很强，互相牵扯调用很多，那么会牵一发而动全身，不利于维护和扩展。 类之间
的设置应该要低耦合，但是每个类应该要高内聚。耦合是类之间相互依赖的尺度。如果每个
对象都有引用其它所有的对象，那么就有高耦合，这是不合乎要求的，因为在两个对象之间，
潜在性地流动了太多信息。
低耦合是合乎要求的：它意味着对象彼此之间更独立的工作。低耦合最小化了修改一
个类而导致也要修改其它类的连锁反应。 内聚是一个类中变量与方法连接强度的尺度。
高内聚是值得要的：因为它意味着类可以更好地执行一项工作。低内聚是不好的，因为
它表明类中的元素之间很少相关。成分之间相互有关联的模块是合乎要求的。每个方法也应
该高内聚。大多数的方法只执行一个功能。不要在方法中添加'额外'的指令，这样会导致方
法执行更多的函数。
推广开来说，这个思想并不限于类与类之间的关系。模块和模块，子系统之间也都要遵
守这个原则，才可以设计出延展性比较强的系统。