主页

索引

模块索引

搜索页面

单一职责原则-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 信息,
    那就可以考虑将这几个属性和对应的方法拆分出来。

备注

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

主页

索引

模块索引

搜索页面