【话唠】一个技术弟兄 21:21:47
慧冬，一般一个类的方法超过多少个，就觉得过于复杂应该拆分了？
【活跃】青润 21:23:53
从需求和代码角度来看待，仅仅有多大的类须要进行拆分的推断标准，没有多少个方法应该拆分的思考。
一般来说，一个用例假设在需求阶段须要通过4层以上的用例阐述才干表述清晰。那就须要拆分。这时候，就须要至少两个类来进行实现了。
【话唠】一个技术弟兄 21:24:49
这个类头文件引了32个我数的
【活跃】青润 21:25:51
这个。也不能算一定大。
可能须要从很多其它的角度来看待，比方性能，处理速度。中间的循环体和调用关系是否清晰。
单纯从方法的数量多少。确实不好说就一定要拆分。拆分类还是从需求的角度来进行思考，会更合理。
这样逻辑关系会更清晰，对于代码的实现层级也更easy把握。
【话唠】一个技术弟兄 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
【活跃】青润 16:22:33
你用的什么工具?
【活跃】青润 16:25:51
你能够考虑用trufun。国产的一个工具，我以前和这家公司做过技术层面的合作，他们一直在坚持。
就是投资一直没有到位，由于他们谈投资的时机不正确，正好是08年開始找，接着金融危机就产生了，随后开发工具厂商频繁倒闭，他们一直坚持到如今。
软件做的不错，标准跟得非常紧。
国外的。比較好的有EA。我是ea中国大陆第一个专业培训师，只是。仅仅做了一单。我就不做了，这家公司的中国区代理太黑。
可是工具做得不错。rose消失后。轻量级工具他们算是相当好的一款。
开源的几款做得都不行，就是一个表面功夫，要做代码层级的关联和导入导出基本等于做梦。
【话唠】一个技术弟兄 16:25:51
ArgoUML 免费的Mac UML工具 版本才0.34
青润 16:26:01
换一个吧。
青润 16:26:33
这一款我没用过，所以不好评价，你能够考虑ea或者trufun。前者能够破解，后者不破解也能用。
【话唠】一个技术弟兄 16:27:28
好 3Q
第三天
一个技术弟兄 21:28:02
@慧冬 有人给我推荐了OmniGraffle 我试了试貌似也不错
青润 22:14:43
哦。
这个我没用过。不了解。
你能够看看。
青润 22:14:58
用得好了，上来分享评价一下。
呵呵
一个技术弟兄 22:27:40
青润 22:54:36
图非常一般。不知道逻辑实现部分做得怎样
2014-10-21
某个參与者 9:00:15
杨健，OmniGraffle 还行，是mac上最好的原型工具，正版卖好几百
还有一个參与者 9:18:58
高大上啊
还有一个技术弟兄 9:20:50
Omni的东西都不廉价的说
一个技术弟兄 9:32:42
嗯 我下的破解版 带序列号
一个技术弟兄 9:32:53
青润 10:35:46
这仅仅是个绘图工具，不是uml工具。这区别大了去了。
青润 10:37:15
没有代码和逻辑部分的实现，仅仅是绘图，也就是半年到一年就能开发好的产品而已——仅指uml部分的图形。实际意义不大，并且，会浪费时间的。青润 10:37:49
网上传言非常好的staruml，去年使用了一下。想看看能否够全然替换rose。结果发现了非常严重的逻辑问题，同一时候在代码层面根本无法支持，也就是个绘图工具。