假如本文对你有帮助的话，救救孩子吧，能够投很多票，投票通道，万分感谢呀~~
前语
软件规划SOLID准则中有一个最基础的准则便是单一责任准则，我想绝大部分的程序员都知道，并且都了解它的意思，乃至觉得很简单。但是往往“看懂”和“会用”是两回事，而“用好”更是难上加难。比方咱们项目，一开始一向和大家强调类的单一责任，跟着事务不断发展，不同的搭档都往这个类“添砖加瓦”，终究导致一个类5000多行，如下图所示，连IDE都受不了，变得卡顿，可想后面保护本钱有多大了，终究为什么会这样呢？又该怎么解决呢？
什么是单一责任准则（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信息，那就能够考虑将这几个特点和对应的办法拆分出来。 - 别的一个很要害的一点是，在为了一个加办法、特点的时分，必定要想清楚这是不是这个归于这个类责任，不清楚，就问问团队其他人，渐渐培养自己的“专业感”，千万不要有无脑地放哪里都行、完成功能就行的心态。
总结
本文探讨了类的单一责任准则，怎么断定一个类是否”专注”，以及详细该怎么做。不仅仅是类，咱们能够进行引申，你的办法足够单一吗？你的模块或许服务足够单一吗？别的，很要害的一点便是你在写代码的时分，必定要动脑子，考虑这段代码写这儿适宜吗？，为这段代码找到一个真实归于它的“家”。多多考虑，那么你必定会变得越来越专业。
假如本文对你有帮助的话，救救孩子吧，能够投很多票，投票通道，万分感谢呀~~
