【设计原则】单一原则S

单一职责原则（Single Responsibility Principle，缩写为SRP）强调每个类或模块应该只负责一个特定的功能。这样做有助于减少类之间的耦合度，提升代码的可读性和可维护性。

单一职责原则的定义相当简单明了，容易理解。它要求一个类只承担一个职责或功能。换句话说，我们不应该设计臃肿的类，而是应该设计粒度小、功能单一的类。从另一个角度来看，如果一个类包含两个或更多不相关的业务功能，那么我们可以说它的职责不够单一，应该将其拆分成多个职责更加独立、粒度更细的类。

需要注意的是，单一职责原则并非绝对规定，而是需要根据具体情况来判断是否需要进行类和模块的拆分。过度拆分可能会导致过多的类和模块，反而增加了系统的复杂度。因此，在应用单一职责原则时，需要权衡考虑，找到适合系统的划分方式。

比如现在有个用户信息实体类，包含id、username、email、phone、province、city、region、address等字段

如果在社交的产品中这个用户地址信息和其他信息一样只是单纯的展示，那么满足单一原则

如果后续加入的电商模块需要地址用在电商物流上，那么就要将地址信息拆分出来，独立成用户物流信息

不能脱离业务，需要结合业务

不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能都是不一样的。

在真实的软件开发中，我们不需要过度地预先设计和未雨绸缪。因此，我们可以先编写一个粗粒度的类，以满足业务需求。随着业务的发展，如果这个粗粒度的类变得庞大且代码量增加，这时候，我们可以对其进行持续重构，将其拆分成更细粒度的类。这种持续重构的方式允许我们根据实际情况不断优化和改进代码结构，以适应业务的变化。

参考下面来判断

1. 当一个类的代码行数、函数或属性过多时，会影响代码的可读性和可维护性，这时候我们需要考虑对类进行拆分；
2. 当一个类依赖的其他类过多，或者依赖该类的其他类过多时，不符合高内聚、低耦合的设计原则，这时候我们需要考虑对类进行拆分；
3. 当一个类拥有过多的私有方法时，我们需要考虑将这些私有方法独立到新的类中，并将其设置为公共方法，以提高代码的复用性；
4. 当给一个类很难起一个合适的名字时，很难用一个业务名词概括，或者只能用一些笼统的词语如"Manager"，这就表明类的职责定义可能不够清晰；
5. 当一个类中大量的方法都是在操作该类的某几个属性时，例如在"UserInfo"的例子中，如果大部分方法都是在操作"address"信息，那么可以考虑将这几个属性和对应的方法拆分出来。

无论是应用设计原则还是设计模式，它们的最终目标都是提高代码的可读性、可扩展性、复用性和可维护性等方面的质量。因此，在考虑是否应用某个设计原则时，我们可以以这些目标作为最终的衡量标准。通过遵循这些原则和模式，我们能够更好地设计出高质量的代码，提高软件系统的可靠性和可持续性发展。