程序 太官僚,是否需要扁平化

05-07-14 搞对象
正在研读 OSWorkflow的源代码。

发现 很多源代码 都是 太官僚。

所谓官僚,就是层次太深,

并不是继承的层次深。

而是调用层次深, 方法不断的委派给其他类的方法。

这让我迷失在调用关系中,顾了后头忘了牵头。

你们说是否需要 向机构改革一样,倡导扁平化?

不要总是不停的委派?

今天借助 Source-Navigator 这个工具也不成功(报错)(据说这个工具是阅读源代码的工具)。

我觉得真需要一个工具,将这个 委托关系链搞清楚。(像时序图一样,通过若干线索,将整个程序的脉络搞清楚)。

banq
2005-07-15 10:01
哈,很形象比喻,其实委托是层次化的必要手段,要实现分层解耦;委派是一种常见基本办法。

看源码会经常发生迷失方向这种情况。

不过委派总是有一个目的,我感觉使用面向接口的扁平化是一种好的设计习惯,委派是OO的一个基本初级手法,好的手法是使用设计模式实现分层。这样代码便于阅读。

我也看过OSWorkflow的源码,特别是它的xml文件读取分析,因为XML文件中有另外一个XML,属于嵌套,它做的比较死。

在我设计的Jdon框架中,也可以XML文件嵌套XML文件,但是这些XML文件是围绕组件的,因为一般一个XML肯定对应一个javaBeans来操作它;这样结对子比较清楚;分离得也好。

搞对象
2005-07-17 21:48
关于扁平化 我有一种感觉,这一定是需要的。

但我还 找不到怎么解决。

OSWorkflow代码写的也有 不少有问题的地方

比如 memory的持久化 实现中,竟然 有一些 关于流程实例创建的逻辑。

我认为这是错误的。

按理说,持久化层(类)就做好持久化就行了。不应该关心业务对象的逻辑。

还有很多,有机会总结。

看来有时候,也不能盲目崇拜大师(还是我没能理解大师的意图?)。

搞对象
2005-07-17 21:56
关于 由Java代码反向生成Sequence图,把握折腾够呛。

先安装 borland together designer.

发现没 反向 功能。

再安装 borland together architect.

找了很久 才找到反向生成Sequence图办法

性能非常慢.

且生成的Sequence图,好像只能表现 第一个 对象发出的消息。不能表现其他对象发出的消息。

borland together for eclipse ,仅支持 eclipse 3.0

猜你喜欢