篮球中的坏味道

Note: First posted on about 2005年3月

/*
 * @Just for fun.
*/

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

   

篮球中的坏味道

  <o:p></o:p>

= 初始化问题 = <o:p></o:p>

 <o:p></o:p>

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

 Solution: 不言自明。 <o:p></o:p>

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

 <o:p></o:p>

= Long Method = <o:p></o:p>

 刷刷刷，一连串的动作，帅呆了(当然是在说俺啦)。 <o:p></o:p>

“怎么做的，教小弟。” <o:p></o:p>

“OK。看着，先运过去，再运过来，再这样，再……” <o:p></o:p>

“@#%*…” <o:p></o:p>

真笨，教了几十遍，他还是没学会… <o:p></o:p>

“这样吧，换个教法，把动作分解，先来个crossover，再…” <o:p></o:p>

真聪明，两三下就学会了!!! <o:p></o:p>

“原来这么简单，一下就会了嘛，怎么不是说？” <o:p></o:p>

“谁叫你不早问!”(似乎流行这么回答) <o:p></o:p>

 <o:p></o:p>

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

注: Large Class等也可用类似作法。 <o:p></o:p>

  <o:p></o:p>

= Long Parameter List = <o:p></o:p>

 <o:p></o:p>

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

 <o:p></o:p>

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

注: 可能会增加类之间的耦合。  <o:p></o:p>

 <o:p></o:p>

= Primitive Obsession = <o:p></o:p>

 <o:p></o:p>

NBA中，一支球队有个属性表示战绩。一开始，为简单起见，可能用一个String对象表示，如”12:<st1:chmetcnv w:st="on" tcsc="0" unitname="”" sourcevalue="7" numbertype="1" negative="False" hasspace="False">7”</st1:chmetcnv>。但如果因需要还得让它能表示胜率，排名等，乍办？解决方案是设计一个战绩对象，使它持有胜、负、胜率、排名等属性，这样就清晰明了了。 <o:p></o:p>

 <o:p></o:p>

Solution: 将那些primitive or near-primitive types改成有意义的对象。 <o:p></o:p>

注: 面向对象就是要面向对象。 <o:p></o:p>

  <o:p></o:p>

= Feature Envy = <o:p></o:p>

 <o:p></o:p>

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

 <o:p></o:p>

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

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

  <o:p></o:p>

= Divergent Change = <o:p></o:p>

 <o:p></o:p>

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

 <o:p></o:p>

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

注:  A module should have only one secret. <o:p></o:p>

  <o:p></o:p>

= Shotgun Surgery = <o:p></o:p>

 <o:p></o:p>

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

 <o:p></o:p>

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

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

  <o:p></o:p>

参考书目 <<Refactoring Workbook>> <o:p></o:p>

<<Refactoring>> <o:p></o:p>

 <o:p></o:p>

不当之处，敬请指出。 <o:p></o:p>

<o:p> </o:p>

评论

2 楼 shaucle 2006-12-02  

just for fun 

1 楼 ouspec 2006-12-02  

哈哈，虽然简单，但是写的很有意思，寓教于乐，不错