《重构》C#版实现（四）switch的多态化处理
上一篇主要重构了Statement方法，在大刀阔斧的调整后，总算是得到了一个易于理解的方法体。当然，其中会带来潜在的效率问题，但记住一点，起码所有的事情都是经过权衡和决策的。可以“果断”来形容，而那种不明就里地乱来属于“武断”又或者说是“鲁莽”的行为当然不被推荐，它们的区别也就在于是否有全面的权衡与决策。
首先，列出到现在为止，Movie类和Rental类的代码如下：
public sealed class RegularPrice : Price{public int Code { get { return 0; } }// ... 其余代码}public sealed class NewReleasePrice : Price{public int Code { get { return 1; } }// ... 其余代码}public sealed class ChildrenPrice : Price{public int Code { get { return 2; } }// ... 其余代码}4.重构完成
六、小结
至此，MovieRentalHouse的整个重构告一段落了。虽然还有些地方可以重构，例如Statement方法还可以通过Extract Method来概念化，但作为训练教程，做到这里足矣。该例子实际上并不复杂，也没有必要进行这么复杂的重构。而这么做的主要目的是为了演示重构方法的价值。倘若将这些代码放到更复杂的交互环境下，很可能重构就是值得的。重点在于，是否需要重构，完全取决于我们对代码质量的评价，以及它是否需要可扩展性、可维护性的判断。
最后，总结一下重构过程中最容易被忽略，也是最值得反复强调的问题如下：
1.了解现有代码的问题，确定代码的重构价值
2.根据重构价值确定重构入手点
3.将处理过程语义（概念）化
4.不要过早介入性能优化这个主题
5.针对变化点重构，而不是兴趣或冲动
6.重构需要自动测试的保障
7.不要过度重构