Controller

你肯定常常见到一个两三千行的 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 字段，用于关联该角色和具体用户。 ...