面向对象设计原则

单一职责原则

单一职责原则，SRP（The Single – Responsibility Principle）规定，一个类只能有一个引起它变化的原因。在SRP中，我们定义一个类的职责就是”改变它的原因“。如果你能想到N个动机去改变一个类，那么这个类就具有多于一个的职责。

原因：如果一个类负责了两个职责P1和P2，那么当我们需要更改P1时，可能会造成P2发生故障。

解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

例如：

上图中Rectangle有两个职责，这就违反了SRP原则。我们可以拆分这个类来使它满足SRP。

遵循单一职责原的优点有：

• 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
• 提高类的可读性，提高系统的可维护性；
• 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

单一职责原则可以用于接口、类、方法的设计中。我们先来看一个关于接口设计的例子。

很多软件都需要管理用户信息，我们经常可以看到如下的接口设计，很简单嘛，get()和set()我们都已经很熟悉了~

（其实我之前很多类都是这么设计的……）但是，这其实存在很大的问题，因为这个接口没有把业务对象（BO，Business Object）和业务逻辑（Business Logic）分离开来，它显得太大了，负责了太多职责。因此，我们可以拆分成下面两个接口。

当然，真实的软件中还是很难完全遵循SRP的，这是因为职责扩散的存在。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。在最开始的设计中，我们的确可以设计出完全符合SRP的类，但随着业务的改变和复杂度加大，某个职责P可以被扩展为P1、P2、P3……这对代码重构带来了很大麻烦。