http://www.cnblogs.com/insus/p/4142264.html

重构if...else...或者switch程序块 为 中介者(Mediator)模式.的思考

首先普世的编程架构好坏评判是SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）

具体来说,就是当有需求的curd时候,代码应该
1)涉及的文件尽可能的少
2)修改的文件行数尽可能的少
3)修改的文件行块间距不应该太长,避免程序员在一个文件中来回移动.鼠标点击数尽可能少.避免影响思路.
4)不应该影响其他模块的.这样就不必全面回归测试.
5)鲁棒性:即使输入错误,也不应该系统崩溃.

那么,我们来看看这篇洋洋得意的重构的结果吧.

原来的代码

logic ( string arg)

{
switch (arg)
{
case "A" :
Do_A();
break;
case "B" :
Do_B();
break;
}

}

// support function group
void DO_A()
{
}

void DO_B()
{
}

他的代码...

开始评测
***增加
客户要求增加功能C
原来的方法
到 logic中间,switch模块尾巴加上 case "C"... 三行
在同一个文件或者其他文件中,增加一个DO_C()方法.
***查询
发现一个logic bug.
设断点在switch...等地方,然后f11进去就可以知道了.
发现是do_a有问题,那么就只需要修改do_a()
***删除
"B"模块不需要了.
到switch哪里,直接删除"B"模块...
*不小心多删了case"C" -- 编译报错,第一时间就修改回来.

***修改
客户要求修改功能B
直接到DO_B()哪里...在ide中,只需要ctrl click就可以直接定位到具体的模块...

对比一下.如果用设计模式,会是什么样的后果.

如果这个方法里面需要2个switch呢.一个是 switch on string 另外一个 switch on int ,那么如果不用泛型.这代码就成线性增加了.

重构if...else...或者switch程序块 为 中介者(Mediator)模式.的思考