【架构设计】你的类足够“专一”吗

前言

软件设计SOLID原则中有一个最基础的原则就是单一职责原则,我想绝大部分的程序员都知道,而且都理解它的意思,甚至觉得很简单。但是往往“看懂”和“会用”是两回事,而“用好”更是难上加难。好比我们项目,一开始一直和大家强调类的单一职责,随着业务不断发展,不同的同事都往这个类“添砖加瓦”,最终导致一个类5000多行,如下图所示,连IDE都受不了,变得卡顿,可想后面维护成本有多大了,究竟为什么会这样呢?又该如何解决呢?

【架构设计】你的类足够“专一”吗插图

欢迎关注微信公众号「JAVA旭阳」交流和学习

什么是单一职责原则(SRP)?

单一职责原则的英文是 Single Responsibility Principle,缩写为 SRP。这个原则的英文描述是这样的:A class or module should have a single reponsibility。如果我们把它翻译成中文,那就是:一个类或者模块只负责完成一个职责(或者功能)。简单来说,一个类只负责完成一个职责或者功能。也就是说,不要设计大而全的类,要设计粒度小、功能单一的类。

上例子,比如,一个类里既包含订单的一些操作,又包含用户的一些操作。而订单和用户是两个独立的业务领域模型,我们将两个不相干的功能放到同一个类中,那就违反了单一职责原则。为了满足单一职责原则,我们需要将这个类拆分成两个粒度更细、功能更加单一的两个类:订单类和用户类。

如何判断类是否够“专一”?

听起来类的单一职责很简单,很容易区分清楚,就比如上面的例子中的用户和订单,那为什么我们在开发过程中还是容易把一个类写的越来越大呢?好吧我们项目中的这个5000多行的类,实际上都是和“指标”这个领域模型的相关操作,所以对于大部分同事很难去界定出来哪些功能归为一类,属于一个职责范围之内的,既然搞不清楚,那么我就都写一起好了,大部分都是这样去写代码的。

这边再用一个实际的例子解释下这种模糊的情况。

比如下面的UserInfo类的设计是否满足单一职责原则呢?

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; // 详细地址
 // ... 省略其他属性和方法...
}
  • 有人认为,UserInfo 类包含的信息都是用户相关的行为,满足单一职责原则。
  • 有人认为,地址信息在 UserInfo 类中,所占的比重比较高,可以继续拆分成独立的 UserAddress 类,UserInfo 只保留除 Address 之外的其他信息,拆分之后的两个类的职责更加单一。

其实是否满足单一职责原则,需要结合具体的业务场景,如果你现在是社交场景中,地址单纯用来展示使用,那么它就是符合单一职责原则。如果在电商场景中,地址就要订单、物流等信息中出现,那么就要做进一步拆分。

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

小结:

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

该具体怎么做?

上面判定一个类是否具备单一职责,还是比较模糊、主观,那么有没有具体地、可执行的标准来判断呢?比如以我们的项目为例:

  • 最关键的一条,如果类中的代码行数、函数或属性过多,影响到代码的可读性和可维护性,就需要考虑对类进行拆分。我们项目后面要求代码不能超过1500行,函数最好不要超过20个。
  • 私有方法过多,我们就要考虑能否将私有方法独立到新的类中,设置为 public 方法,供更多的类使用,从而提高代码的复用性;
  • 类中大量的方法都是集中操作类中的某几个属性,比如,在 UserInfo 例子中,如果一半的方法都是在操作 address 信息,那就可以考虑将这几个属性和对应的方法拆分出来。
  • 另外一个很关键的一点是,在为了一个加方法、属性的时候,一定要想清楚这是不是这个属于这个类职责,不清楚,就问问团队其他人,慢慢培养自己的“专业感”,千万不要有无脑地放哪里都行、实现功能就行的心态。

总结

本文探讨了类的单一职责原则,如何判定一个类是否"专一",以及具体该如何做。不仅仅是类,我们可以进行引申,你的方法足够单一吗?你的模块或者服务足够单一吗?另外,很关键的一点就是你在写代码的时候,一定要动脑子,思考这段代码写这里合适吗?,为这段代码找到一个真正属于它的“家”。多多思考,那么你一定会变得越来越专业。

欢迎关注微信公众号「JAVA旭阳」交流和学习
更多学习资料请移步:程序员成神之路

文章来源于互联网:【架构设计】你的类足够“专一”吗

THE END
分享
二维码