前言

软件设计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旭阳」交流和学习
更多学习资料请移步：程序员成神之路

你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧

本文标题：【架构设计】你的类足够“专一”吗-创新互联
本文路径：http://lszwz.com/article/dehihi.html