如何使用单一职责原则

编程设计原则SOLID中，Single Responsibility Principle是最基础的一个原则，看起来比较简单，但是实际用好并不容易

如何判断是否符合单一职责原则

• 没有判断职责是否单一的标准，同一个类在不同的业务范畴可能就有不同的结论。

比如用户信息中的地址信息，如果是一个简单的用户管理系统，地址信息属于用户，满足单一职责，但是如果是电商系统里的用户，地址可能会作为收货地址，通信地址等，就需要把地址信息独立出来

实际编码中的一些信号

如果出现以下情况，就是可能违反单一职责原则的信号

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

重构为单一职责的类或模块

类的职责也不是越单一越好，还是要考虑扩展性、可读性等，所有设计原则的目的瓯都市为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性。

参考

• 设计模式之美: 对于单一职责原则，如何判定某个类的职责是否够“单一”？