05 | 大类：如何避免写出难以理解的大类？
分模块的程序
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了如何避免编写难以理解的大类，通过分析大类的表现形式和产生原因，以及解决方法，强调了程序模块化设计的重要性。作者首先指出大类的典型特征，包括字段过多和职责不单一，导致类的复杂度超出人们的理解范围。随后，作者提出了分模块的程序设计思想，强调了对程序进行模块划分的重要性，以降低人们的理解成本。解决大类问题的方法是将大类拆分成若干个小类，根据职责和字段分组进行拆分，以实现单一职责原则。文章还强调了软件设计对于写好代码的重要性，以及程序设计语言提供的类集合构造方式。总的来说，本文通过讲解大类的问题及解决方法，强调了程序模块化设计的重要性，以及如何避免写出难以理解的大类。
《代码之丑》，新⼈⾸单¥59
全部留言(29)
- 最新
- 精选
qinsi正如类太大会超出人的理解范畴，类太多也会。举个java的例子，做业务开发时大部分需求都可以通过spring boot完成，但如果要对spring进行定制，需要理解的内容就多了一个数量级。框架本身在满足更多需求的同时不断重构，类的职责越来越单一，数量也越来越多。虽然每个改动都有正当的理由，但如果不知道这些改动的历史，一下子就被那么多类糊一脸，任谁也是吃不消的。个人理解这可能是在业务优先的场景下，两害相权取其轻的结果吧。作者回复: 认为类太多是个问题，我在文章中已经说了一个角度，这里再补充一个角度。这里有一个假设是，一上来就要把所有的类理解掉， 然而，这种假设是不成立的，作为 Java 程序员，你不会去看所有 JDK 里的类，也不会看 Spring 所有的类。 一般的做法是理解主线，然后，根据需要了解相应的类， 这是做事方法的问题。不能因为我们可能要面对所有代码，就一下子去吃透所有的代码，这是普通人做不到的。 所以，类的数量多少不是问题，通过怎样的方式，降低代码理解的难度才是我们要考虑的问题。
2021-01-09338
wang_acmilan目前在做嵌入式的项目，里面的C代码如郑老师所言，大部分都是以“效率”为名，写的巨长无比。 我有一个问题想咨询郑老师，我们的项目不算法，4万行左右，我在进行一代往二代的重构，我个人感觉应该把功能都拆开，以不同文件夹的层级方式进行代码的整理；而组内的同事以及外包的员工觉得代码不算多，一个文件夹，几个文件一把就搞定了，没必要搞那么复杂。 这个问题就和老师这篇文章所述有一点不一样了：如果觉得代码架构和代码逻辑能够理解，是不是clean code的必要性或者说急迫性就没有那么大了。先以交付为目标进行coding，后续再看情况。作者回复: 马斯洛需求层次理论告诉我们，人有不同层次的追求。生存是底线，总有人会告诉你，温饱解决就行。 写代码也一样，功能实现就可以了，代码规模不大，可以理解。问题在于，等规模大了，你真的改得动吗？ 你的代码为什么要改动？还不是一代的代码改起来很吃力了。为什么吃力了？是因为功能实现不了吗？还不是代码可维护性差。为什么可维护性差？还不是根本不知道可维护性好的代码是什么样。 你不妨推演一下，按照他们的建议写代码，距离走回老路上，还有多远的距离。 既然有机会建立新的标准，既然有机会知道可维护的代码长什么样，为什么要按照老路走呢？ 如果知道什么是“积重难返”，就会懂得“勿以善小而不为”的价值所在了。
2021-01-09517
邓志国看了郑大的例子，正合我当前做法，给自己吃颗定心丸。我现在java一个4万行代码的项目，最大的类不到300行代码。普遍100行以下。很多是得益于对象健身操。操练了对象健身操，对面向对象会有更深刻理解作者回复: 你做得已经很好了！
2021-01-11210
布凡老师，请问一下，一般来说实体的大小和数据表的列是对应关系的，User类拆分出了Contact这个类，那么数据库的层面是否也应该差分出一个Contact表还是把信息都存储在User表的列中呢？作者回复: 都可以，根据自己的需要。很多人纠结的点在于没做过“类分开，表在一起”，其实，很多框架是支持的。
2021-02-098- life吖有的时候，拆分和聚合是需要做取舍的。比如，微服务的聚合层，是为了适配和性能考虑会做裁剪或聚合，不可避免的会出现些大类，此时可以进行字段分组，但是聚合后的大类是无法进行拆分。
作者回复: 我的理解，你问的问题是，在微服务中，有专门把多个服务的结果聚合起来，返回给客户端，这是你所说的聚合层。你的问题是，在这个聚合层里，表示请求和应答的类可能会比较大，改怎么办。 根据这个理解，我的回答是，这里的聚合层扮演的角色其实一个防腐层，它本身的职责就是和请求应答去做一一应对。一般来说，这样类行为很单一，主要的职责就是数据转换。对于这种类，大一点是可以的，因为它不会对业务造成什么影响。重点在于，这个类里没有业务。 如果你想把类里面的字段做一个分组，可以研究一下不同的转换库，比如，在 Java 中把 JSON 和对象进行相互转换的 Jackson。看看它们怎么可以把不同类的字段和协议中的平铺字段直接映射，肯定有方案的。 不过，最后要提醒你的一个重点是，简单的聚合并不是一个好办法，而是需要谨慎地设计通信协议，这才是保证类比较小的根本办法。
2021-01-1128 
Hobo将user里的联系信息单独拆出一个类来以后，我要对外暴露一个修改联系信息的方法是应该放user里还是放contact里？作者回复: 如果 user 类是整个的根，修改联系方式就可以在 user 类里提供一个入口，然后，再调用 contact 类。
2021-01-117
明老师，我也有个一直找不到平衡点的问题，就是类爆炸问题，如果拆分的类太多 会不会出现累爆炸的问题呢，从而影响系统性能，这个有没有个比较数字化的标准呢。还是我看这个问题的角度就完全不对。（ps 拍个马屁：我真的越来越崇拜老师了😍😍）作者回复: 不要把性能放在这里说事，因为这属于发力找错了对象。性能优化肯定不是在这个层面上的，而是要从一个系统的层面上进行考量。 类爆炸，首先是，啥叫类爆炸？类多就是类爆炸吗？那岂不是所有代码都在一个类里完成就是最好的。类多不是问题，问题是过度设计造成的难以理解的结构才是问题。
2021-01-1127
人月聊IT每个类两个字段？？？？作者回复: 我知道大多数人做不到，但我们应该知道更高的追求是什么。
2021-01-0955
熊斌我们的项目中，或者是用到的类似于JPUSH这种开源软件中，都存在“大类”的问题。最头疼的是遇见没有注释说明的大类，里面罗列了很多字段、函数，但是你都没法一眼就看出来各自都是干嘛的，只能先猜一下，完了之后根据调用关系去梳理。 最近用PHP进行二次开发，用到一个扩展包，里面的入口class写得巨长无比...... 目前来看，把类写小，越小越好能做到的是凤毛麟角呀。也可能是我见得太少了作者回复: 不意外，大多数代码都是有问题的，Clean Code是稀缺的。
2021-01-095
Sinvi今天有了新的追求作者回复: 加油！
2021-01-094