public static void main(String[] args){
CommandLoader cl=new DefaultCommandLoader(new DefaultShowCommand());
cl.excute("executeShowList",null);
}
}
public interface CommandLoader {
void excute(String commandName,Object[] argument);
}
public class DefaultCommandLoader implements CommandLoader {
private ShowCommand showCommand;
private HashMap subCommandMap=new HashMap();
public DefaultCommandLoader(ShowCommand showCommand){
this.showCommand=showCommand;
init();
}
private void init() {
Method[] allMethod=this.showCommand.getClass().getMethods();
for(int i=0;i<allMethod.length;i++){
Method m=allMethod;
if(m.getName().startsWith("execute")){
subCommandMap.put(m.getName(), m);
}
}
}
public void excute(String commandName, Object[] argument) {
Method m=(Method) this.subCommandMap.get(commandName);
if(m==null){
throw new NullPointerException("not found command");
}
try{
m.invoke(this.showCommand,argument);
}
catch(Exception e){
throw new RuntimeException("Load command["+m.getName()+"error");
}
}
}
public interface ShowCommand {
public void executeShowList();
public void excuteShowString();
public void executeShowInteger();
public void executeShowLong();
}
public class DefaultShowCommand implements ShowCommand {
public void excuteShowString() {
System.out.println(String.class.getName());
}
public void executeShowInteger() {
System.out.println(Integer.class.getName());
}
public void executeShowList() {
System.out.println(List.class.getName());
}
public void executeShowLong() {
System.out.println(Long.class.getName());
}
}
]]>
Z么会业务逻辑层用if elseQ其实用者的目的也是Z重用Q但是这是面向过E编E的重用Q程序员只看C码重用，因ؓ他看到if else几种情况下大部分代码都是重复的，只有个别不同Q因此用if else可以避免重复代码Qƈ且认是模板Template模式?/p>
他范的错误是Q程序员只从代码q行序q个方向来看待它的代码，q种思维cM水管或串行电路，水沿着水管动Q代码运行次序）Q当遇到几个分管Q子）Q就分到q几个分子在流动，q里q当于到代码的if else处了?/p>
而用OOQ则首先打破q个代码׃向下序{同于运行时的先后@序这个规律，代码l构不由执行循序军_Q由什么决定呢Q由OO设计Q设计模式会取代q些if elseQ但是最后L׃个Service{ȝ按照q行序l装q些OO模块Q只有一处，q处可包含事务，一般就是ServiceQEJB中是Session bean?/p>
一旦需求变化，我们更多的可能是Service中各个OO模块Q甚x只改动Service中的OO模块执行序pW合需求?/p>
q里我们也看到OO分离的思\Q将以前q程语言的一个Main函数d分解Q将q行序与代码其他逻辑分离开来，而不是象面向q程那样混ؕ在一赗所以有人感慨，OO也是要顺序的Q这是肯定的Q关键是q行序要单独分d来?/p>
是否有if else可以看出你有没有运行顺序分d家?/p>
设计模式的切入口
l常有h反映Q设计模式是不错Q但是我很难用到Q其实如果你使用if else来写代码Ӟ除显C控制以外）Q就是在写业务逻辑Q只不过使用单的判断语句来作为现实情늚替代者?/p>
q是以大家熟悉的论坛帖子Z子，如ForumMessage是一个模型，但是实际中帖子分两种性质Q主题脓Q第一个根_和回帖（回以前帖子的帖子Q，q里有一个朴素的解决ҎQ?br />建立一个ForumMessageQ然后在ForumMessage加入isTopicq样判断语句Q注意，你这里一个简单属性的判断引入Q可能导致你的程序其他地方到处存在if else 的判断?/p>
如果我们改用另外一U分析实现思\Q以对象化概늜待，实际中有主题贴和回帖Q就是两U对象，但是q两U对象大部分是一致的Q因此，我将ForumMessage设ؓ表达主题_然后创徏一个承ForumMessage的子cForumMessageReply作ؓ回帖Q这P我在E序地方Q如Service中，我已l确定这个Model是回帖了Q我q接下溯ؓForumMessageReply卛_Q这个有点类似向Collection攑օ对象和取出时的强制类型{换。通过q个手段我消灭了以后E序中if else的判断语句出现可能?/p>
从这里体CQ如果分析方向错误，也会D误用模式?/p>
讨论设计模式举例Q不能没有业务上下文场景的案例，否则无法军_是否该用模式Q下面D两个Ҏ的例子：
W一. q个帖子中D例的W一个代码案例是没有上下文的Q文中只说明有一D代码：
| main() {
ifQcase AQ{ //do with strategy A }else(case B){ //do with strategy B }else(case C){ //do with strategy C } } |
q段代码只是Ua的代码，没有业务功能Q所以，在这U情况下Q我们就很难定使用什么模式，是一定用{略模式{，也逃不q还是用if else的命q，设计模式不是法Q不能将一D|无意义的代码变得单了Q只能将其体现的业务功能更加Ҏ可拓展了?/p>
W二.?a target="_blank">q个帖子中，作者D了一个PacketParser业务案例Q这D代码是体现业务功能的，是一个数据包的分析，作者也比较了各U模式用的不同Q所以我们还是用动态代理模式或Command模式来消灭那些可能存在的if else
׃上两个案例表明：业务逻辑是我们用设计模式的切入点，而在分解业务逻辑Ӟ我们习惯则可能用if else来实玎ͼ当你有这U企图或者已l实C码了Q那么就应该考虑是否需要重构Refactoring了?br />
if else替代?/strong>
那么实战中，哪些设计模式可以替代if else呢？其实GoF设计模式都可以用来替代if elseQ我们分别描q如下：
当数据对象存在各U可能性的状态，而且q种状态将会媄响到不同业务l果Ӟ那么我们应该考虑是否使用状态模式，当然Q用状态模式之前，你必首先有内存状态这个概念，而不是数据库概念Q因为在传统的面向过E的/面向数据库的pȝ中，你很隑֏现状态的Q从数据库中d某个|然后Ҏq个D行代码运行分，q是很多初学者常q的事情。参考文?状态对象：数据库的替代?/a>
使用传统语言思维的情况还有：使用一个类整数变量标识状态：
public class Order{ private int status; //说明Q? //status=1 表示订货但ؓ查看 Q?/p> //status=2 表示已经查看未处理； //status=3 表示已经处理未付?/p> //status=4 表示已经付款未发?/p> //status=5 表示已经发货 } |
上述c设计，无疑是将cMZl语a的函数来使用Q这样导致程序代码中存在大量的if else?br />
当你面几种法或者公式选择Ӟ可以考虑{略模式Q传l过E语a情况是：从数据库中读取算法数|数?表示{略1Q例如保存到数据库；数gؓ2表示{略2Q例如保存到XMl文g中。这里用if else作ؓ{略选择的开兟?
传统q程的思维情况是：如果客户端发Zh1?A"Q那么我调用A.javaq个对象来处理；如果代号??B"Q我p用B.java来处理，通过if else来判断客L发送过来的代码Q然后按事先U定的对应表Q调用相应的cL处理?br />
MVC模式的传l语a误用和Command模式cMQ在一个ActioncMQ用if elseq行前后台调度，如果客户端传送什么命令；我就调用后台什么结果；如果后台处理什么结构，再决定推什么页面，不过Q现在我们用Struts/JSFq样MVC模式的框架实现者就不必范这U低U错误?br />
职责链模式和Command模式是可选的Q如果你实在不知道客L会发Z么代P也没有一个事先定义好的对照表Q那么你只能~写一个个cd运气一h开q个包看一下就可以。与Command是不同在AOP vs Decorator一文中有分析?br />
代理对象可以是符合某U条件的代表者，比如Q权限检验，传统面向q程思维是：当一个用L陆后Q访问某资源Ӟ使用if elseq行判断Q只有某U条件符合时Q才能允许访问，q样权限判断和业务数据逻辑混ؕ在一P使用代理模式可以清晰分离Q如果嫌不太好，使用动态代理，或者下面AOP{方式?br />
其实使用filterqo器也可以替代我们业务中的if elseQ过滤器起到一U过滤和{选作用，符合本qo器条件的对象拦截下来做某件事情，q就是一个过滤器的功能，多个qo器组合在一起实际就是if else的组合?br /> 所以，如果你实在想不出什么办法，可以使用qo器，过滤器看成防火墙就比较好理解，当客L有一个请求时Q经q不同性质的防火墙Q这个防火墙是拦截端口的Q那个防火墙是安全检查拦截等{。过滤器也如同红蓝白各种光o镜；U色滤镜只能通过光线中的U色拦截了；蓝色滤镜光U中的蓝色拦截下来，q实际上是对光线使用if elseq行分解?br />
如图Q通过一个个条gqo器我们立体地实现了对信号的分，如果你用if elseQ说明你是将图中的条?/2/3/4合ƈ在一P在同一个地方实现条件判断?br /> 需要深入了解过滤器的实现细节和微小区别Q请参考文章：AOP vs Decorator
OO设计的ȝ
q有一U伪模式Q虽然用了状态等模式Q但是在模式内部实质q是使用if else或switchq行状态切换或重要条g判断Q那么无疑说明还需要进一步努力。更重要的是Q不能以模式自居Q而且ZCZh?/p>
真正掌握面向对象q些思想是一件困隄事情Q目前有各种属于揪着自己头发向上拔的解说Q都是误人子弟的Q所以我觉得初学者读Thinking in JavaQJava~程思想Q是没有用，它试图从语言层次来讲OO~程思想Q非常失败，作ؓ语言参考书可以Q但是作为Java体现的OO思想的学习资料，错了?/p>
OO~程思想是一U方法论Q方法论如果没有应用比较Q是无法体会q个Ҏ论的特点的，是古代一个方法论Q悟是靠挑水砍柴这些应用才能体会?/p>
那么OO思想靠什么应用能够体会到了？是GoF设计模式QGoF设计模式是等于Y件h员的挑水砍柴{基本活Q所以，如果一个程序员q基本活都不会，他何以自居OOE序员？从事OO专业设计~程q个工作Q如果不掌握设计模式基本功，p一个做和尚的h不愿意挑水砍_他何以立个行业？早就被师傅赶下山?/p>
最后ȝQ将if else用在地方还可以Q如单的数值判断；但是如果按照你的传统习惯思维Q在实现业务功能时也使用if elseQ那么说明你的思维可能需要重塑，你的~程l验丰富，传统q程思维模式容易根p固，想靠自己改变很困难；接受专业头脑风暴培训?/p>
用一句话ȝQ如果你做了不少pȝQ很久没有用if else了，那么说明你可能真正进入OO设计的境C。（q是本h自己发明的实战性的衡量考核标准Q?/p>
]]>
http://dev.mysql.com/doc/refman/5.1/en/connector-j-reference-replication-connection.html
]]>
2007.8.24
]]>