单一职责原则：一个类或模块应该只做一件事情

我就是我 2023-10-13 09:37 22阅读 0赞

# 单一职责原则：一个类或模块应该只做一件事情 #

### 文章目录 ###

*  单一职责原则：一个类或模块应该只做一件事情
 *  一、含义
 *  二、遵循的价值
 *   *  1、代码的清晰性和可读性
     *  2、代码的可维护性
     *  3、代码的可扩展性
     *  4、代码的重用性
     *  5、提高开发效率
 *  三、缺点
 *   *  1、类或模块数量增加
     *  2、跨类或模块协作复杂性增加
     *  3、需要更多的设计和抽象
     *  4、可能导致过度设计
 *  四、最佳实践
 *   *  1、确定类或模块的职责
     *  2、高内聚性
     *  3、保持类的简单性
     *  4、适度的抽象和接口定义
     *  5、单元测试支持
     *  6、审查和重构

# 一、含义 #

单一职责原则（Single Responsibility Principle）是面向对象编程中的一个原则，它要求一个类或模块只负责完成一个独立的功能或任务。通俗地说，就是**一个类或模块应该只做一件事情**，并且做好这件事情。

**核心作用是降低程序之间的耦合度，从而增强可读性、可维护性、可扩展性、可重用性，提高开发效率。**

# 二、遵循的价值 #

## 1、代码的清晰性和可读性 ##

当一个类或模块只负责完成一个独立的功能时，代码的职责变得**清晰明确**。这使得代码更易于**阅读和理解**，提高了代码的**可读性**。其他开发人员在查看代码时能够迅速理解其功能和作用。**（清晰可读，便于协作）**

## 2、代码的可维护性 ##

一个类或模块只负责一项具体任务，当需要对某个功能进行**修改或修复bug**时，我们**只需要关注特定的类或模块**，而不必担心影响到其他部分的代码。这样降低了修改代码的**风险**，简化了维护工作，提高了代码的可维护性。**（缩小关注范围，降低耦合，缩小代码的影响范围，降低修改可能带来的风险）**

## 3、代码的可扩展性 ##

当系统需要**新增功能或修改需求**时，遵循单一职责原则的代码更容易进行**扩展**。由于每个类或模块的**职责明确**，我们可以针对特定的类或模块进行修改和扩展，而不会影响到其他部分的代码。这样有利于系统的演进和扩展，提高了代码的可扩展性。**（职责明确，耦合低，影响范围小，方便扩展）**

## 4、代码的重用性 ##

遵循单一职责原则的代码通常具有更高的重用性。当一个类或模块只负责一个特定的功能时，它可以被其他模块或系统在需要该功能时进行复用。这样可以减少重复编写类似功能的代码，提高了代码的重用性，同时也有助于减少系统中的冗余代码。**（耦合低，最小化闭环，重用时存在冗余代码的概率低）**

## 5、提高开发效率 ##

单一职责原则可以提高开发效率。由于代码职责明确，**可读性好，维护和扩展方便**，开发人员在开发过程中可以更快速地理解和修改代码，减少了开发时间和调试时间，提高了开发效率。

# 三、缺点 #

## 1、类或模块数量增加 ##

遵循单一职责原则通常需要将功能拆分为多个独立的类或模块，这可能导致**类或模块的数量增加**。如果过度拆分，系统中可能会出现过多的小类或模块，增加了代码的复杂性和维护的成本。因此，在实践中需要权衡拆分的程度，以避免过度拆分带来的问题。**（类或模块数量太多，编写代码时很繁琐，因此要注意适度拆分）**

## 2、跨类或模块协作复杂性增加 ##

当将功能拆分到不同的类或模块时，可能需要引入更多的协作和交互。这可能增加代码之间的依赖关系，导致系统的复杂性增加。如果不恰当地划分职责，可能会导致过多的交互和通信，使代码难以理解和维护。**（遵循单一职责原则导致系统拆分出来的“零件”都比较小，实现一个功能可能会依赖多个小“零件”，这也一定程序上增加了耦合，增加了复杂性。另外就是每个人对“单一职责”的认识是不同的，有的人认为蒸馒头是一个职责，有人认为和面、烧水、放蒸屉都是一个职责，对粒度的划分有认识偏差）**

## 3、需要更多的设计和抽象 ##

为了遵循单一职责原则，需要进行更细致的设计和抽象。这需要更多的时间和精力来定义类的职责和接口，以及处理类之间的关系。这可能增加了开发的复杂性和设计的难度。**（增加系统设计的复杂性，简单地讲就是在系统开发时，需要花更多的时间考虑该如何适当地使用单一职责原则，考虑如何做到“适当”拆分。）**

## 4、可能导致过度设计 ##

过度拆分功能和类的职责，为了追求单一职责原则可能导致系统的过度设计。如果某个功能本身并不复杂，但为了满足单一职责原则而引入了过多的类和抽象，可能会使代码变得冗余和复杂，增加了系统的维护成本。**（如果是无限小的拆分，那么程序的复杂度就太大了！）**

# 四、最佳实践 #

## 1、确定类或模块的职责 ##

在设计过程中，要仔细考虑每个类或模块的职责，确保它只负责完成一个独立的功能或任务。职责应该是**清晰、具体和可量化**的，避免模糊和重叠的职责定义。**（单一职责，功能清晰）**

## 2、高内聚性 ##

> 高内聚性（High Cohesion）是面向对象编程中的一个原则，它指的是一个类或模块内部的成员（方法和属性）在逻辑上紧密相关，都围绕着完成一个特定的功能或任务。简而言之，高内聚性意味着**一个类或模块应该只做一件事**，并且把这件事做好。

每个类或模块应该具有高内聚性，即类内部的成员和方法都应该与该类的职责密切相关。类内的成员变量和方法应该有明确的目的和关联，不应包含与其职责无关的内容。**（高内聚，一个类或模块应该只做一件事，类中的属性和方法与要实现的功能息息相关，不包含无关内容）**

## 3、保持类的简单性 ##

每个类或模块应该尽量保持简单，不要承担过多的功能。如果一个类变得庞大复杂，可能意味着它违反了单一职责原则。在这种情况下，考虑将功能拆分成更小的类或模块，每个类只负责一个明确的功能。**（简单类，只负责一个功能）**

## 4、适度的抽象和接口定义 ##

在划分类的职责时，适度地使用抽象和接口可以提供灵活性和可扩展性。通过定义适当的接口，可以降低类之间的耦合度，增强代码的可维护性和可扩展性。但要避免过度的抽象和接口定义，以免引入不必要的复杂性。**（适度抽象，降低耦合）**

## 5、单元测试支持 ##

遵循单一职责原则可以方便进行单元测试。每个类或模块只负责一个特定的功能，因此可以更容易地编写针对该功能的单元测试。这有助于提高代码的质量和稳定性。**（单一功能 => 单元测试）**

## 6、审查和重构 ##

定期审查代码并进行必要的重构，以确保代码仍然符合单一职责原则。随着需求的变化和系统的演进，代码的职责可能会发生变化，因此需要及时调整和重构代码结构。**（我认为重构是非常伟大的，很多时候我回顾自己写过的代码，发现曾经写的东西是那么糟糕，当然有时候也会发现原来的自己是那么聪明，回顾代码并重构是非常重要的，有用的，也能快速提升自己的编码水平。另外，重构一定程度上是因为在开发之初所涉及的功能模块较少，随着开发的继续，逐渐有了更广阔的视野，可以对一些通用的内容进行一些抽象）**