今天突发奇想做了一个重构的练习,因为在读代码的时候看到了别人在大量的业务逻辑中有一个很庞大的switch在控制逻辑,看完后觉得很头痛,就自己模拟了一下此类情况的重构过程。
首先,有可能现有代码是这样的:ifelse判断
string type = "A";
if (type == "A")
{
Console.WriteLine("A");
}
else if (type == "B")
{
Console.WriteLine("B");
}
else if (type == "C")
{
Console.WriteLine("C");
}
else if (type == "D")
{
Console.WriteLine("D");
}
然后有人改成了这样:switch
string type = "A";
switch (type)
{
case "A": Console.WriteLine("A"); break;
case "B": Console.WriteLine("B"); break;
case "C": Console.WriteLine("C"); break;
case "D": Console.WriteLine("D"); break;
}
然后又有人提取成这样的:提取了枚举
enum SuperType
{
A,
B,
C,
D
}
SuperType type = SuperType.A;
switch (type)
{
case SuperType.A: Console.WriteLine("A"); break;
case SuperType.B: Console.WriteLine("B"); break;
case SuperType.C: Console.WriteLine("C"); break;
case SuperType.D: Console.WriteLine("D"); break;
}
然后有人尝试修改成了这样:工厂模式
interface IDoWork
{
void DoWork();
}
class DoWorkA:IDoWork
{
public void DoWork()
{
Console.WriteLine("A");
}
}
class DoWorkFactory
{
public static IDoWork CreateDoWork(SuperType type)
{
IDoWork result = null;
switch (type)
{
case SuperType.A: result = new DoWorkA(); break;
case SuperType.B: result = new DoWorkB(); break;
case SuperType.C: result = new DoWorkC(); break;
case SuperType.D: result = new DoWorkD(); break;
}
return result;
}
}
个人认为到这里已经可以了,需要类型扩展的时候就分三步:
1. 添加新的扩展类
2. 添加新的枚举类型
3. 扩展工厂的Switch
当然因为只是例子,所以工厂就轻松的搞定了这次重构,如果稍微复杂的创建过程可以使用抽象工厂模式。如果想再优化,可以使用Spring中的IOC思想,把东西记录到配置文件中,而在这里就是通过反射来动态创建,这样就不需要扩展工厂的创建方法,也干掉了工厂中的这个大的Switch,但是要注意反射的性能问题,虽然我也经常在编写代码的时候追求极限,但是至于什么是头?过度的重构出飘逸的代码而不管程序性能?相信这样我的lead会kill掉我的,呵呵。
以上均属个人学习经验和结果,如果出入或者不认同的朋友望请不吝指教。