java重构代码时切换案例过多
我继承了一个需要重构的应用程序。下面的内容让我有些头疼。原始源代码有太多的切换情况,如下所示:
class Girl {
//...
void traditionalMakeUp() {
switch (type) {
case FRENCH:
frenchMakeUp();
break;
case AFRICAN:
africanMakeUp;
break;
case NORWEGIAN:
norwegianMakeUp();
.....
case KOREAN:
koreanMakeUp();
.....
}
}
}
我正试图像这样重构它:
abstract class Girl {
//...
abstract void makeUp();
}
class French extends Girl {
void makeUp() {
// makeUP
}
}
class African extends Girl {
void makeUp() {
// makeUP
}
}
class Norwegian extends Girl {
void makeUp() {
// makeUP
}
}
// Somewhere in client code
girl.makeUp();
这是正确的方法吗?如果我的交换机中没有20多个案例,策略模式就可以了
此外,我不愿意仅仅为了适应策略设计模式而添加20多个类。还有其他重构它的好方法吗
# 1 楼答案
根据应用程序中基于属性
type
的Girl
存在的其他操作/开关,这里似乎需要调用继承如果这是唯一的开关,你可以像下面这样做
用一个抽象方法-compose()定义一个枚举女孩,然后在那里为该枚举类型实现该方法
您的实用程序类如下所示
客户端代码
您可以根据存在的功能数量以及如何组合常用功能(即调用,
Utility.koreanMakeUP()
from和inmakeUp()
)来组织多个实用程序类# 2 楼答案
重构这样一个场景有多种方法
遗传当然是这里考虑的另一种选择。但是,取决于层次结构的深度和你是否需要在层次结构中创建辅助类或中间类来共享共同的代码,我会考虑构图。虽然
#makeUp
的功能因女孩的类型不同而有所不同,但可能在语义上存在相似之处,您可以构建小的代码单元(组件),然后以类似组件的方式将其拼接在一起# 3 楼答案
我宁愿在这里为女孩作曲,为化妆做传承。根据你的领域不同,法国女孩可以化妆。让一个女孩包含一个化妆类型的对象
然后我会这样做:
在客户端代码中:
这是为了更接近您尝试的重构,但它不能解决决策问题。也许你可以有一张地图来帮助你选择正确的化妆类型