一篇codereview报告--类的职责分配与代码冗余

     以下内容引自某个项目的一篇codereview报告    

   

       目前的codereview好像对代码的结构、代码的冗余关注的太少，这两天看了一下，发现xx系统里存在不少的冗余，这些都是由一些代码功能片段放置位置的不合理，类的职责分配不合理造成的。

譬如：

对于领域模型CreditCont，它的状态是否终止、有效、关闭；它是否已过期；它是否已生效等均属于领域模型CreditCont的本质特征，这些特征的判断会频繁的被其他类所使用，但是，目前对这些特征的判断都是由其他类负责.

譬如当某个类里的某个方法需要判断授信协议是否过期时，就直接在这个方法里写上判断语句，这样当多个类的多个方法都需要该判断功能时，就会到处都充斥着重复的判断语句.

譬如在类ContractStatusHelper里，有三个方法需要对授信协议是否过期进行判断，三个方法里都充斥着同样的判断语句：

        在类ContractAmountHelper里，也存在同样的冗余：

 

       在类ContractValidatorFacadeImpl里也有同样的代码片段。

 

像这种对某个领域模型本质特征进行判断的功能，应该由领域模型自己负责（即将这样的功能提炼为一个方法并移入领域模型本身，实际上这也是Martin Flower在重构中所提倡的），这样其他类需要对该特征进行判断的时候，就只需要委托领域模型去判断了，达到了复用的目的，而且每个类的职责也更清晰。

譬如上面对授信协议是否过期的判断就可以放在CreditCont中

        其他类需要判断授信协议是否过期时，只需要委托调用CreditCont的isNotDue方法就可以了，

 这种结构使得代码的语义也更清新，看见函数的名称就知道该行代码的功能。

 

而按照目前的代码结构，不仅使代码充斥着冗余，而且导致有些类非常复杂，功能很多（因为它负责了很多本不应该由它负责的功能），而有些类又非常的单薄，是贫血的（除了一堆get/set方法，啥事都不做），只有属性，没有任何行为或只有弱行为的类都是病态的。而且在同一个方法里，如果需要对多个本质特征进行判断，采用目前的方式，就会导致方法里到处充斥着判断语句，只见木不见林。

 

像这种情况，目前代码里比较多，譬如对于领域模型Bill，判断账单是否已出账，这也属于Bill的本质特征，而且也会经常被其他类用到，但目前这种功能代码片段都是放在其他类中的。

 

建议：对于某个方法里的一些代码片段，如果该片段所用到的方法、变量都属于（或大部分属于）另外一个类，而与该片段所在的类没有任何关系（或者关系很少），应该将该片段提炼为一个方法并移入到另外一个类中，如果该片段所需要的一些变量在另一个类中无法获取，则可以作为该方法的输入参数传过去。

 

距发这篇报告又过了一年，期间还是发现很多系统都存在这种问题，职责分配不合理是导致系统复杂混乱、代码冗余的罪魁祸首。