设计原则-单一职责原则

在编程大环境中，评价代码组织方式质量的好坏涉及到各个方面，如代码的可读性、可维护性、可复用性、稳定性等各个方面。而在面向对象语言中也可以通过以下各个方面：

类中方法的设计
类中属性的设计
类(接口、抽象类、普通类)的设计
类与类之间的关联关系(组合、继承、实现)的设计

设计原则(SOLID)也是在这些方面可能出现的问题中总结出来的，虽然并不一定能够全部都满足原则要求，但是尽可能满足更能够提到代码组织质量。本文下面将逐步分析单一职责原则的具体含义以及应用。

一、单一职责原则概念

单一职责原则(Single Responsibility Priciple, SRP)规定了代码中的类应该有且仅有一个原因引起类的变更。换句话说，一个类仅负责单一业务职责，意味着仅当该职责发生改变时，该类才需要被改动。相反，类改动后，仅该类负责的业务逻辑改动同时不影响其他业务逻辑。
由此可以看出，单一职责原则提出了一个编程标准，用“变化原因”、“职责”等来衡量一个类的设计的合理性。

类的职责唯一性首先能够显著提高代码的可读性，一般来说，日常开发中书写的类名基本按照其功能或职责来进行命名，单一职责的类代码维护起来十分方便，增加开发效率。如果类的职责不唯一，当其中一种业务场景需要改动时，如给类添加一个属性，我们很难判断这次改动是否会影响到其他业务场景，降低了代码的可维护性以及稳定性。

二、职责划分

我们现在知道了类的设计要尽可能的遵循单一职责，即一个类仅负责单一业务职责。设计原则听起来、理解起来都十分简单，但是在实际业务开发中，能够做到类单一职责的项目有多少？完全遵循单一职责进行开发几乎是天人说梦。这其中主要的原因有以下几点：① 不同项目所涉及的业务有所不同，不同业务针对类职责的划分也有所不同。划分太粗不满足单一职责，划分太细类数量急速膨胀，也增加了代码可维护性的难度。② 项目代码基本由多人、跨时空进行开发，每个人对业务理解的不同就会导致类的设计(职责划分)存在差异化。③ 项目中有的类可能根本做不到单一职责原则，比如工具类、启动类等业务功能辅助类以及一些实现类。其中第①个问题是最具备矛盾性，最难把握的问题。那问题是我们又该根据什么如何划分职责呢？
接口、类的职责划分是不可度量的，但也不是无迹可寻、任意划分的。接口职责划分根据项目而异、因环境而异。考虑以下两个场景的区别：
(1) 公司业务主要客服相关，需要你描述下客服的行为过程。在此间你需要设计电话相关类。
在这里插入图片描述
如上图所示，由于电话种类有很多，因此设计了一个IPhone接口。接口中定义了客服需要利用电话执行的业务逻辑，如根据电话号码拨打电话、和客户交谈以及结束通话等操作。
首先思考下，在该场景中，这个电话接口符合单一职责原则吗？符合！因为客服业务不可能拆分电话，自身业务利用的是电话产品，因此电话的接口设计只需要考虑电话制造商提供给其他使用者的接口即可。
② 公司业务主要是电话制造厂相关，需要你描述下电话制造的行为过程。在此间你需要设计电话相关类。
我们还是首先思考下，在该场景中，场景①设计的电话接口符合单一职责原则吗？不符合！因为电话制造厂会涉及到电话原理底层，电话制造生产线中会分为不同的模块，比如电话通信所需要的协议管理、数据传送方式等。如果使用上述统一接口，会导致协议管理发生变化或数据传送方式发生变化都会引起类的变化。
在这里插入图片描述
如上图所示，将原先IPhone接口拆分为两个接口，具体电话实现类同时实现该两个接口，即可。当某一个模块发生改动时，只需要改动该接口相关的即可。

接口职责的划分需要根据具体的业务而定

三、原则适用对象

在上一节例子中，我们将IPhone接口拆分为2个接口，在具体实现类中实现两个接口完成所有功能。那我们为什么不选择组合呢？使用组合方式也能实现需求目标，但是使用组合方式会导致多个实现类间耦合严重、类的数量增加等问题，会增加设计的复杂性。但是，还有个疑问是，不论是通过组合方式还是继承方式，接口虽然是满足单一职责了，但是实现类并不满足单一职责。因为最终还是将两个职责融入到一个类中了。
类的单一职责几乎很难实现，退一步来说，由于我们总是面向接口编程，向外提供的是接口，而不是具体实现类。因此我们必须要保证设计的接口是单一原则的。
单一职责原则的本质实际上是要求代码是局部高内聚，低耦合的。因此类的方法也需要尽可能遵循单一职责原则，划分职责的依据也需要根据具体项目来进行划分。

四、实际应用

在实际的业务开发中，尽可能地满足单一职责的设计要求，这样能够保证接口的复杂性降低，实现的业务逻辑都有清晰明确的定义，同时提高了代码可读性、可维护性以及稳定性。在类、方法设计之初，职责的划分最为重要，具体划分依据具体业务而定。一方面考虑业务未来发展是否需要更细粒度的划分，另外一方面根据业务发展现状及时对业务代码进行重构。
在单一职责原则的实际落地过程中，千万不要盲目拆分类，并非是越小、越简单的类越好，相反，这种过分细分类的做法容易导致类的剧增，降低代码可读性以及可维护性。