SOLID 原则

由 5 个设计原则组成的，它们分别是：单一职责原则、开闭原则、里式替换原则、接口隔离原则和依赖反转原则，依次对应 SOLID 中的 S、O、L、I、D 这 5 个英文字母。

单一职责原则定义

英文：Single Responsibility Principle，缩写为 SRP。描述：A class or module should have a single responsibility，一个类或者模块只负责完成一个职责（或者功能）

通俗来讲，就是一个类只负责完成一个职责或者功能，不要设计大而全的类，要设计颗粒度小、功能单一的类。换个角度说，一个类包含了两个或者两个以上业务不相干的功能，那就可以认为它的职责不够单一，应该将它拆分成多个功能单一、粒度更细的类。

判断职责是否足够单一

从类的定义来看，判断类的职责是否足够单一看似很简单，其实不然。

评价一个类的职责是否足够单一，并没有一个非常明确的，可以量化的标准。在真正的软件开发中，也没有必要过于未雨绸缪，过度设计。可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，就可以将这个粗粒度的类，拆分成几个更细烈度的类。这就是所谓的持续重构。

几条判断原则：

• 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性。
• 类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想。
• 私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性。
• 比较难给类起一个合适名字，很难用一个业务名词概括。
• 类中大量的方法都是集中操作类中的某几个属性。

类的职责越单一越好？

为了满足单一职责原则，是不是把类拆得越细就越好呢？答案是否定的。

单一职责原则通过避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。同时，类职责单一，类依赖的和被依赖的其他类也会变少，减少了代码的耦合性，以此来实现代码的高内聚、低耦合。但是，如果拆分得过细，实际上会适得其反，反倒会降低内聚性，也会影响代码的可维护性。

讨论

问：对于如何判断一个类是否职责单一，如何判断代码行数过多，还有哪些其他的方法吗？

职责：该类对与其他类而言是否为“黑盒”。

代码行数：方法间是否存在重复代码？方法间是否有足够的复用性？部分方法是否可以被其他类是否？属性对该类是否必要，需要移除吗？

问：单一职责原则，除了应用到类的设计上，还能延伸到哪些其他设计方面吗？

方法，模块，功能点等。