单一职责原则-SRP¶

Single Responsibility Principle

备注

A class or module should have a single responsibility

问题:这个实例是否满足单一职责原则呢:

public class UserInfo {
  private long userId;
  private String username;
  private String email;
  private String telephone;
  private long createTime;
  private long lastLoginTime;
  private String avatarUrl;
  private String provinceOfAddress; // 省
  private String cityOfAddress; // 市
  private String regionOfAddress; // 区
  private String detailedAddress; // 详细地址
  // ...省略其他属性和方法...
}

解答:我们不能脱离具体的应用场景:

1. 如果在这个社交产品中，用户的地址信息跟其他信息一样，只是单纯地用来展示，那 UserInfo 现在的设计就是合理的。
2. 如果这个社交产品发展得比较好，之后又在产品中添加了电商的模块
    用户的地址信息还会用在电商物流中，那我们最好将地址信息从 UserInfo 中拆分出来，
    独立成用户物流信息（或者叫地址信息、收货信息等）。
3. 如果做这个社交产品的公司发展得越来越好，公司内部又开发出了很多其他产品（可以理解为其他 App）
    公司希望支持统一账号系统，也就是用户一个账号可以在公司内部的所有产品中登录。
    这个时候，我们就需要继续对 UserInfo 进行拆分，将跟身份认证相关的信息（如email、tel）抽取成独立的类

备注

不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能都是不一样的。在某种应用场景或者当下的需求背景下，一个类的设计可能已经满足单一职责原则了，但如果换个应用场景或着在未来的某个需求背景下，可能就不满足了，需要继续拆分成粒度更细的类。

备注

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

小技巧:指导意义和可执行性的几条判断原则:

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

备注

不管是应用设计原则还是设计模式，最终的目的还是提高代码的可读性、可扩展性、复用性、可维护性等。我们在考虑应用某一个设计原则是否合理的时候，也可以以此作为最终的考量标准。