设计模式之单一职责原则

设计模式之单一职责原则

学习 极客时间 王争 的第12讲 单一职责

什么是单一职责原则

单一职责原则SRP(Single Responsibility Principle) ，英文描述：a class or module should have a single responsibility。class即类的概念，而module 模块可以理解为是一个比类更粗粒度的概念，多个类组成模块，如最近流行的微服务架构中的微服务可以类比是一个单一职责的模块。

举例说明

定义一个UserInfo类

public class UserInfo{
	private long userId;
	private String username;
	private String email;
	private String tel;
	private String provinceOfAddress // 省
	private String CityOfAddress; // 市
	...
}

对于这个类的设计是否符合单一职责原则呢？

  首先看注释的字段信息，省市等地理信息，如果省市等信息只是用来进行展示，不存在业务操作则可以看作是用户的基本信息，符合单一原则。如果后期可能做电商业务需要快递地址则可能独立出来一个UserAddress比较好，此时就不符合单一职责原则了。
  我们对类的设计尽可能的要满足单一原则，但是一个类是否满足单一原则，还会受到业务的约束，在不同的业务场景下，一个类的设计可能只符合某个场景下的单一原则，所以我们在实际设计和开发阶段应设置一个粗粒度的符合当前业务模型的单一原则类，然后根据业务变化，抽象出更符合业务的多个细粒度的单一原则类，符合极限编程思想也就是满足软件持续重构思想持续重构。

如何设计一个单一职责的原则的类或者模块

1、 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分；
2、 类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分；
3、 私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性；
4、 比较难给类起一个合适名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context之类的词语来命名，这就说明类的职责定义得可能不够清晰；
5、 类中大量的方法都是集中操作类中的某几个属性，比如，在 UserInfo中，如果一般的方法都在操作address信息，就可以考虑将address属性和方法拆出来

对一个类也不能一味的设计成单一职责

  如果符合业务的类或者模块使其尽可能的符合单一职责原则，那么可能导致类的拆分更多的类，类之间相互关联，导致维护性变差，因为改一处功能导致所有拆分出去的类都需要适配。例如：序列化和反序列化，如果拆分成2个类，则序列化方式改变则反序列化方式也应该改变。