篮球中的坏味道

篮球中的坏味道

 

 

= 初始化问题 =

 

打半场开始之前当然要热身啦，上次俺就是没热身出现exception－－扭了脚，到现在还痛呢，555…

 

Solution: 不言自明。

注: 为避免没初始化，常伴有大量 if(xx==null) 之类语句出现，该问题主要是把null错看成对象的缺省值。解决此问题的一个技巧是引入一“NullObject”作为其缺省值，即把对没初始化对象的调用转换为对这个“NullObject”缺省对象方法的调用，这样便可消除这些冗余的 if(xx==null)。

 

 

= Long Method =

 

刷刷刷，一连串的动作，帅呆了(当然是在说俺啦)。

“怎么做的，教小弟。”

“OK。看着，先运过去，再运过来，再这样，再……”

“@#%*…”

真笨，教了几十遍，他还是没学会…

“这样吧，换个教法，把动作分解，先来个crossover，再…”

真聪明，两三下就学会了!!!

“原来这么简单，一下就会了嘛，怎么不是说？”

“谁叫你不早问!”(似乎流行这么回答)

 

Solution: 先在这个方法体中加上注释，然后将每个注释块提出为一个方法，就这么简单。

注: Large Class等也可用类似作法。

 

 

= Long Parameter List =

 

为写一篇关于篮球的文章(够无聊的吧)。需要一些数据，如篮球的质量，体积，弹性系数等。你没必要把这些数据一一后告诉俺，只要抱加一个篮球给俺，这些数据自然就搞定了。

 

Solution: 如果这几个参数组合在一起有意义，引进一个对象，使其持有这几个参数，然后使这个对象成为此方法的参数，并对该方法作相应的修改。

注: 可能会增加类之间的耦合。

 

 

= Primitive Obsession =

 

NBA中，一支球队有个属性表示战绩。一开始，为简单起见，可能用一个String对象表示，如”12:7”。但如果因需要还得让它能表示胜率，排名等，乍办？解决方案是设计一个战绩对象，使它持有胜、负、胜率、排名等属性，这样就清晰明了了。

 

Solution: 将那些primitive or near-primitive types改成有意义的对象。

注: 面向对象就是要面向对象。

 

 

= Feature Envy =

 

俺有许多必杀技，其中有一技就是，听好了，那就是叫小王先crossover，再变向，再急停…。咦，怎么都是小王？唉，这个必杀技不关俺的事，给小王算了。

 

Solution: 如果一方法总是调用其他某个对象的方法，就把该方法移到相应的对象中去。

注: 有时候出现这种情况是有道理的，如策略模式和访问者模式。

 

 

= Divergent Change =

 

一次比赛，俺当裁判，吹哨，记分，记时俺都一人包办。半场下来，因来回奔波累得不成人样，还因忙不过来吹了不少“黑哨”。于是，又找来两人，一人记分记时，另一人和俺各管半场。呵呵，果然下半场轻松加愉快，而且几乎没有误判，不过俺的工资减了一半…

 

Solution: 如果有多种原因使得一个对象改变，就说明这个对象责任过多，得减减负(三减？)。可将该对象按需求分解为多个对象。

注:  A module should have only one secret.

 

 

= Shotgun Surgery =

 

这次比赛，俺和小王两人当主裁，两个主裁，没搞错吧，不用急，还有更离谱的呢，那就是俺吹哨，小王负责做犯规手势，有创意吧!不过分工似乎太“明确”了吧。呵呵。

 

Solution: 如果一个简单的改变牵涉到几个对象，也就是说一件事的责任被分散到几个对象中，这时，你要做的就是从这些对象中提取出这整件事，然后对其他对象作相应的调整，这可能使几个对象合并成一个对象。

注: 当然也有特例，如观察者模式中的模型与视图，这是因为视图和模型通常需要独自的改变。

 

 

参考书目 <<Refactoring Workbook>>

<<Refactoring>>

 

不当之处，敬请指出。