代码重构：重复的Switch（Repeated Switches）

什么是重复的Switch（Repeated Switches）

• 定义：在不同的地方反复使用同样的switch逻辑
• 影响：影响可维护性：每当需要增加一个选择分支时，必须找到所有switch，并逐一更新
• 改进目标：消除重复switch，提升代码可修改/可扩展能力
• 方法：多态取代条件表达式

案例1：重复Switch对可维护性的影响

代码背景

• 某同学退休后养了些宠物，现在想用代码得出每天需要再各种宠物上付出的金钱和精力。
• 其中client为客户端，在Main方法中传递Pet对象到server端的KeepPetCosts方法，并获取返回的Cost对象

重构目标

• 分析PetCosts类中重复Switch的坏味道及其对可维护性的影响
• 重构：用多态取代重复switch

症状

• 在样例类PetCosts的不同的方法里，重复的switch反复出现
• 实际业务代码中，相同或相似的switch可能散落在多个类文件中

问题

• 假设该同学家里又新增了鸟类宠物Bird，那么我们就需要在图示所有位置新增一个case分支
• 实际业务代码中，每增加一个新分类，就要修改散落在多个文件的switch，造成散弹式修改，代码难扩展，可维护性较差

重构参考

• 方法下移到子类

• 重构后结果展示

重构后

• 入口方法getKeepPetCosts中使用工厂来获取各类宠物实例
• 当需要新增一类宠物时，创建新的类，并在入口处新增创建对应实例的分支即可
• 可创建Species枚举进一步优化

扩展

• 当前重构前提为不改变客户端调用方式（即不改变对外行为），如果可修改上层调用，此处可进一步改进：对外提供KeepPetCosts接口以及各宠物对应实现，由客户端决定调用哪个方法，这样可以在对代码无侵入的情况下进行扩展，拥有更好的可扩展性

总结