[技术讨论][全程建模]一个类应该有多少方法？多大就需要拆分？

【话唠】一个技术弟兄 21:21:47

慧冬，一般一个类的方法超过多少个，就认为过于复杂应该拆分了？

【活跃】青润 21:23:53

从需求和代码角度来看待，只有多大的类需要进行拆分的判断标准，没有多少个方法应该拆分的思考。

一般来说，一个用例如果在需求阶段需要通过4层以上的用例阐述才能表述清楚，那就需要拆分，这时候，就需要至少两个类来进行实现了。

【话唠】一个技术弟兄 21:24:49

这个类头文件引了32个我数的

【活跃】青润 21:25:51

这个，也不能算一定大。

可能需要从更多的角度来看待，比如性能，处理速度，中间的循环体和调用关系是否清晰。

单纯从方法的数量多少，确实不好说就一定要拆分，拆分类还是从需求的角度来进行思考，会更合理。

这样逻辑关系会更清晰，对于代码的实现层级也更容易把握。

【话唠】一个技术弟兄 21:27:48

教程上给的三消游戏例子只有3个类，我实现差不多的功能大概用了快50个类

【活跃】青润 21:28:32

这方面要看需求和架构层面的考虑，类的多少，并不能说明一定复杂或者一定更合理。

这种简单的定义，不太恰当。

【话唠】一个技术弟兄 21:28:57

嗯

主要就我自己在写

【活跃】青润 21:29:42

建议你可以考虑一下做uml的反工，然后从类与类之间的关系来进行一下思考，或者能找到答案。

【话唠】一个技术弟兄 21:30:12

做了一部分

UML图

打算功能完成后拿一个星期出来整理图

能复用的部分再抽出来

以后做别的游戏的时候再用

【活跃】青润 21:43:40

嗯。

【活跃】青润 21:44:56

用一下协作图，可以让你看清楚类之间的关系以及是否有关系冗余。

时序图只能表示时间顺序管理，初期构建系统时用处很大，但是，返工分析时，协作图用处最大。

【话唠】一个技术弟兄 22:06:45

还没画过协作图现在画的都是类图

【活跃】青润 22:50:11

去研究一下吧，类图之间的关系，就是协作图的大用处。

表现出类的行为和类之间关系的交互。

很有用。

【话唠】一个技术弟兄 23:20:27

好

第二天

【话唠】一个技术弟兄 12:10:22

@慧冬 协作图看起来挺好画的，可能是我用这个工具有点问题，消息的方向调整不好

【话唠】一个技术弟兄 12:10:38

青润 10:35:46

这只是个画图工具，不是uml工具，这差别大了去了。

青润 10:37:15

没有代码和逻辑部分的实现，只是画图，也就是半年到一年就能开发好的产品而已——仅指uml部分的图形。实际意义不大，而且，会浪费时间的。

青润 10:37:49

网上传言很好的staruml，去年使用了一下，想看看是否可以完全替换rose，结果发现了很严重的逻辑问题，同时在代码层面根本无法支持，也就是个画图工具。

为何是一个人？也有善意的提醒：