1000copy@gmail.com

发表人:1000copy | 发表时间: 2007年二月05日, 21:54

BizObject中有IM的很多方法，和其他业务都混合在一起，修改的时候因为依赖的原因，投鼠忌器，不管轻易的动。

把它移动出来。

在移动出来前，这些业务我还不熟悉，移动出来需要熟悉业务，但是移动本身也就是业务的熟悉过程，不过，一定是每个步骤都是从静态上看和前一步步骤的结果是等量置换的。

就是说，这些修改本身不动业务，仅仅动结构。同时动业务和结构很有诱惑力，但是现在这个阶段还不敢。

最直接的想法就是写一个IM类，然后把所有IM函数都移动到新的单元，就这么干。

失败，因为新的IM类内的方法依赖于原来的BizObject，IM需要use Bizobject，而BizObject作为核心大对象，当然有责任创建IM类。于是就是一个双向依赖了。

回到原点。

当然还可以一点点的找到这些依赖，IM用到的所有函数，然后Biz和IM共同继承或者聚合这个函数组构成的类。不过这可以很难的事情，花费很多过程，最后要么发现不成功回到原点，要么成功了，但是前后步骤不是等量置换，导致业务和原来的在一次次的小变换中，逐步的走样，和原始的需求渐行渐远。

要不得。

我要的重构，必须在一个小时内可以完成，干净利落，绝不拖泥带水的完成等量置换。

因为这个重构是否恰当，必须在修改的过程中做决定，时间一长，过程中的决定越多，必定和初衷背道而驰。

既然如此，不如建立一个函数把Biz作为TObject传递过来。就是说procedure CallIM(Biz : TObject ); 注意Biz参数是TObject的类型，在函数的实现部分把Biz 转型为TBiz即可。

当然IM类要放到uIM单元的Implement部分。这样Biz大大类就可以uses uIM，调用CallIM，把Self传递到IM类的对象内。

可以这样用到的函数，下一步必须被替换为类，这样的中间的，必然被替换的方案，我何必做呢？有些不甘心。

既然一个不甘心，一个不符合我的敏捷原则，而更好的还没有出来，在思考中，准确的说做了些小小的，不管痛痒的等量置换和标注后，这些楼草打兔子的过程中，结束了一天的工作。

在家中思考了一下，第一个方案的好处是明确，敏捷，易于实施，而且只要定位于中间方案，其他也没有什么关系，既然看不清楚，当然要先迈出一个小步了。

第二天动手。

IM和Biz分离的中间方案实施后，IM和Biz的关系，职责的划分，依赖，开始变得一目了然。进而IM，CS，PH，RS都逐一分离出来，Biz的一部分被依赖的公共方法下沉到Biz的父类WA。瓜分豆析，Biz从全能对象变成协调对象，其他IM，cs，ph，rs变成专业对象。

这四个业务对象一旦分离，他们的职责就开始逐步明确，原来的函数脚手架因为4业务对象的依赖关系明确而不再必要，顺理成章的完成历史使命。

中间方案转移到正式方案了。

回头看，中间方案的选择就是这次快速进入状态的最重要决定，欲先取之，必先与之，成功的目的，需要一些看起来不那么美好的，但是很实际的垫脚石。

-----------------

本文构思于2周前，一直写不出来，把它记载一张纸上，总是决定不爽，现在写出来了，真的很畅快。

下一篇文章预告： “干掉一根线”