软件设计原则 — 单一职责原则

一、定义

There should never be more than one reason for a class to change。

一个类应该有且只有一个变化的原因，即一个类只干一件事，担任一个职责。

为什么将不同的职责分离到单独的类中是如此的重要呢/p>

因为每一个职责都是一个变化的中心。当需求变化时，这个变化将通过更改职责相关的类来体现。

如果一个类拥有多于一个的职责，则这些职责就耦合到在了一起，那么就会有多于一个原因来导致这个类的变化。对于某一职责的更改可能会损害类满足其他耦合职责的能力。这样职责的耦合会导致设计的脆弱，以至于当职责发生更改时产生无法预期的破坏。

我们有一个 Class 负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致另一个职责的功能发生故障。这样一来，这个 Class 存在两个导致类变更的原因。如何解决这个问题呢们就要给两个职责分别用两个 Class 来实现，进行解耦。后期需求变更维护互不影响。这样的设计，可以降低类的复杂度，提高类的可读性 ，提高系统的可维护性 ， 降低变更引起的风险 。

二、案例

案例一：用户中心

在做项目时，会接触到用户，角色管理这些模块，基本上使用的都是 RBAC 模型， 通过分配和取消角色来完成用户权限的授予和取消。

现在这样一种场景，把用户管理，修改用户信息，增加角色等维护信息写到一个类中进行管理。如下类

分析上面的类会发现，这样的设计是非常不合理，用户的属性和用户的行为是两种不同的业务模式。

应该把用户的信息抽取成一个 BO(Business Object，业务对象)， 把行为抽取成一个Biz (Business Logic, 业务逻辑) 。重新设计的类如下