共计 2436 个字符，预计需要花费 7 分钟才能阅读完成。
你肯定常常见到一个两三千行的 controller 类，类之所以倒退成如此宏大，有如下起因：
长函数太多
类外面有特地多的字段和函数
质变引起量变，可能每个函数都很短小，但数量太多
1 程序的 modularity
你思考过为什么你不会把 all code 写到一个文件？因为你的潜意识里明确：
雷同的功能模块无奈复用
复杂度远超出集体了解极限
一个人了解的货色是无限的，在国内互联网麻利开发环境下，更没有人能相熟所有代码细节。
解决简单的最无效计划就是分而治之。所以，各种程序设计语言都有本人的模块划分（modularity）计划：
从最后的按文件划分
到起初应用 OO 按类划分
开发者面对的不再是细节，而是模块，模块数量显然远比细节数量少，了解老本大大降低，开发效率也进步了，再也不必 996，每天都能和妹纸多聊几句了。
modularity，实质就是合成问题，其背地起因，就是集体理解能力无限。
说这么多我都懂，那到底怎么把大类拆成小类？
2 大类是怎么来的？
2.1 职责不繁多
最容易产生大类的起因。
CR 一段代码：
该类持有大类的典型特色，蕴含一坨字段：这些字段都缺一不可吗？
userId、name、nickname 等应该是一个用户的根本信息
email、phoneNumber 也算是和用户相关联
很多利用都提供应用邮箱或手机号登录形式，所以，这些信息放在这里，也能了解
authorType，作者类型，示意作者是签约作者还是一般作者，签约作者可设置作品的付费信息，但一般作者无此权限
authorReviewStatus，作者审核状态，作者成为签约作者，须要有一个申请审核的过程，该状态字段就是审核状态
editorType，编辑类型，编辑能够是主编，也能够是小编，权限不同
这还不是 User 类的全副。但只看这些内容就能看出问题：
普通用户既不是作者，也不是编辑
作者和编辑这些相干字段，对普通用户无意义
对那些成为作者的用户，编辑的信息意义不大
因为作者不能成为编辑。编辑也不会成为作者，作者信息对成为编辑的用户无意义
总有一些信息对一部分人毫无意义，但对另一部分人又必须。呈现该问题的症结在于只有“一个”用户类。
普通用户、作者、编辑，三种不同角色，来自不同业务方，关怀的是不同内容。仅因为它们都是同一零碎的用户，就把它们都放到一个用户类，导致任何业务方的需要变动，都会重复批改该类，重大违反繁多职责准则。所以破题的要害就是职责拆分。
尽管这是一个类，但它把不同角色关怀的货色都放在一起，就愈发得臃肿了。
只需将不同信息拆分即可：
public class User {
private long userId;
private String name;
private String nickname;
private String email;
private String phoneNumber;
…
}
public class Author {
private long userId;
private AuthorType authorType;
private ReviewStatus authorReviewStatus;
…
}
public class Editor {
private long userId;
private EditorType editorType;
…
}
复制代码
拆出 Author、Editor 两个类，将和作者、编辑相干的字段别离移至这两个类里。这俩类别离有个 userId 字段，用于关联该角色和具体用户。
2.2 字段未分组
有时感觉有些字段的确都属于某个类，后果就是，这个类还是很大。
之前拆分后的新 User 类：
public class User {
private long userId;
private String name;
private String nickname;
private String email;
private String phoneNumber;
…
}
复制代码
这些字段应该都算用户信息的一部分。但仍然也不算是个小类，因为该类里的字段并不属于同一种类型的信息。如，userId、name、nickname 算是用户的根本信息，而 email、phoneNumber 则属于用户的联系方式。
需要角度看，根本信息是那种一旦确定个别就不变的内容，而联系方式则会依据理论状况调整，如绑定各种社交账号。把这些信息都放到一个类外面，类稳固水平就差点。
据此，可将 User 类的字段分组：
public class User {
private long userId;
private String name;
private String nickname;
private Contact contact;
…
}
public class Contact {
private String email;
private String phoneNumber;
…
}
复制代码
引入一个 Contact 类（联系方式），把 email 和 phoneNumber 放了进去，前面再有任何对于联系方式的调整就都能够放在这个类外面。此次调整，把不同信息重新组合，但每个类都比原来要小。
前后两次拆分到底有何不同？
后面是依据职责，拆分出不同实体
前面是将字段做了分组，用类把不同的信息别离封装
大类拆解成小类，实质上是个设计工作，根据繁多职责设计准则。
若把大类都拆成小类，类的数量就会增多，那人们了解的老本是不是也会减少呢？这也是很多人不拆分大类的借口。
各种程序设计语言中，本就有如包、命名空间等机制，将各种类组合在一起。在你不须要开展细节时，面对的是一个类的汇合。再进一步，还有各种程序库把这些打包进去的货色再进一步打包，让咱们只有面对简略的接口，而不用关怀各种细节。
软件正这样层层封装构建进去的。
最初
如果你感觉此文对你有一丁点帮忙，点个赞。或者能够退出我的开发交换群：1025263163 互相学习，咱们会有业余的技术答疑解惑
如果你感觉这篇文章对你有点用的话，麻烦请给咱们的开源我的项目点点 star: https://gitee.com/ZhongBangKe… 不胜感激！
