实例解析Ruby设计模式编程中Strategy策略模式的使用
今天你的leader兴致冲冲地找到你，希望你可以帮他一个小忙，他现在急着要去开会。要帮什么忙呢？你很好奇。
他对你说，当前你们项目的数据库中有一张用户信息表，里面存放了很用户的数据，现在需要完成一个选择性查询用户信息的功能。他说会传递给你一个包含许多用户名的数组，你需要根据这些用户名把他们相应的数据都给查出来。
这个功能很简单的嘛，你爽快地答应了。由于你们项目使用的是MySQL数据库，你很快地写出了如下代码：
require'mysql'
classQueryUtil
deffind_user_infousernames
@db=Mysql.real_connect("localhost","root","123456","test",3306);
sql="select*fromuser_infowhere"
usernames.eachdo|user|
sql<<"username='"
sql<<user
sql<<"'or"
end
putssql
result=@db.query(sql);
result.each_hashdo|row|
#处理从数据库读出来的数据
end
#后面应将读到的数据组装成对象返回，这里略去
ensure
@db.close
end
end
这里根据传入的用户名数组拼装了SQL语句，然后去数据库中查找相应的行。为了方面调试，你还将拼装好的SQL语句打印了出来。
然后，你写了如下代码来测试这个方法：
qUtil=QueryUtil.new qUtil.find_user_info["Tom","Jim","Anna"]
现在运行一下测试代码，你发现程序出错了。于是你立刻去检查了一下打印的SQL语句，果然发现了问题。
select*fromuser_infowhereusername='Tom'orusername='Jim'orusername='Anna'or
拼装出来的SQL语句在最后多加了一个or关键字！因为for循环执行到最后一条数据时不应该再加上or，可是代码很笨地给最后一条数据也加了or关键字，导致SQL语句语法出错了。
这可怎么办呢？
有了！你灵光一闪，想出了一个解决办法。等SQL语句拼装完成后，截取到最后一个or之前的位置不就好了么。于是你将代码改成如下所示：
require'mysql'
classQueryUtil
deffind_user_infousernames
@db=Mysql.real_connect("localhost","root","123456","test",3306);
sql="select*fromuser_infowhere"
usernames.eachdo|user|
sql<<"username='"
sql<<user
sql<<"'or"
end
sql=sql[0..-"or".length]
putssql
result=@db.query(sql);
result.each_hashdo|row|
#处理从数据库读出来的数据
end
#后面应将读到的数据组装成对象返回，这里略去
ensure
@db.close
end
end
使用String的截取子字符串方法，只取到最后一个or之前的部分，这样再运行测试代码，一切就正常了，打印的SQL语句如下所示：
select*fromuser_infowhereusername='Tom'orusername='Jim'orusername='Anna'
好了，完工！你自信满满。
你的leader开完会后，过来看了下你的成果。总体来说，他还挺满意，但对于你使用的SQL语句拼装算法，他总是感觉有些不对劲，可是又说不上哪里不好。于是他告诉了你另一种拼装SQL语句的算法，让你加入到代码中，但是之前的那种算法也不要删除，先保留着再说，然后他又很忙似的跑开了。于是，你把他刚刚教你的算法加了进去，代码如下所示：
require'mysql'
classQueryUtil
deffind_user_info(usernames,strategy)
@db=Mysql.real_connect("localhost","root","123456","test",3306);
sql="select*fromuser_infowhere"
ifstrategy==1
usernames.eachdo|user|
sql<<"username='"
sql<<user
sql<<"'or"
end
sql=sql[0..-"or".length]
elsifstrategy==2
need_or=false
usernames.eachdo|user|
sql<<"or"ifneed_or
sql<<"username='"
sql<<user
sql<<"'"
need_or=true
end
end
putssql
result=@db.query(sql);
result.each_hashdo|row|
#处理从数据库读出来的数据
end
#后面应将读到的数据组装成对象返回，这里略去
ensure
@db.close
end
end
可以看到，你leader教你的拼装算法，使用了一个布尔变量来控制是否需要加个or这个关键字，第一次执行for循环的时候因为该布尔值为false，所以不会加上or，在循环的最后将布尔值赋值为true，这样以后循环每次都会在头部加上一个or关键字，由于使用了头部添加or的方法，所以不用再担心SQL语句的尾部会多出一个or来。然后你为了将两个算法都保留，在find_user_info方法上加了一个参数，strategy值为1表示使用第一种算法，strategy值为2表示使用第二种算法。
这样测试代码也需要改成如下方式：
qUtil=QueryUtil.new qUtil.find_user_info(["Tom","Jim","Anna"],2)
这里你通过参数指明了使用第二种算法来拼装SQL语句，打印的结果和使用第一种算法是完全相同的。
你立刻把你的leader从百忙之中拖了过来，让他检验一下你当前的成果，可是他还是一如既往的挑剔。
“你这样写的话，find_user_info这个方法的逻辑就太复杂了，非常不利于阅读，也不利于将来的扩展，如果我还有第三第四种算法想加进去，这个方法还能看吗？” 你的leader指点你，遇到这种情况，就要使用策略模式来解决，策略模式的核心思想就是把算法提取出来放到一个独立的对象中。
为了指点你，他不顾自己的百忙，开始教你如何使用策略模式进行优化。
首先定义一个父类，父类中包含了一个get_sql方法，这个方法就是简单的抛出了一个异常：
classStrategy defget_sqlusernames raise"Youshouldoverridethismethodinsubclass." end end
然后定义两个子类都继承上述父类，并将两种拼装SQL语句的算法分别加入两个子类中：
classStrategy1 defget_sqlusernames sql="select*fromuser_infowhere" usernames.eachdo|user| sql<<"username='" sql<<user sql<<"'or" end sql=sql[0..-"or".length] end end classStrategy2 defget_sqlusernames sql="select*fromuser_infowhere" need_or=false usernames.eachdo|user| sql<<"or"ifneed_or sql<<"username='" sql<<user sql<<"'" need_or=true end end end
然后在QueryUtil的find_user_info方法中调用Strategy的get_sql方法就可以获得拼装好的SQL语句，代码如下所示：
require'mysql'
classQueryUtil
deffind_user_info(usernames,strategy)
@db=Mysql.real_connect("localhost","root","123456","test",3306);
sql=strategy.get_sql(usernames)
putssql
result=@db.query(sql);
result.each_hashdo|row|
#处理从数据库读出来的数据
end
#后面应将读到的数据组装成对象返回，这里略去
ensure
@db.close
end
end
最后，测试代码在调用find_user_info方法时，只需要显示地指明需要使用哪一个策略对象就可以了：
qUtil=QueryUtil.new qUtil.find_user_info(["Tom","Jim","Anna"],Strategy1.new) qUtil.find_user_info(["Jac","Joe","Rose"],Strategy2.new)
打印出的SQL语句丝毫不出预料，如下所示：
select*fromuser_infowhereusername='Tom'orusername='Jim'orusername='Anna' select*fromuser_infowhereusername='Jac'orusername='Joe'orusername='Rose'
使用策略模式修改之后，代码的可读性和扩展性都有了很大的提高，即使以后还需要添加新的算法，你也是手到擒来了！
策略模式和简单工厂模式结合的实例
需求：
商场收银软件，根据客户购买物品的单价和数量，计算费用，会有促销活动，打八折，满三百减一百之类的。
1.使用工厂模式
#-*-encoding:utf-8-*-
#现金收费抽象类
classCashSuper
defaccept_cash(money)
end
end
#正常收费子类
classCashNormal<CashSuper
defaccept_cash(money)
money
end
end
#打折收费子类
classCashRebate<CashSuper
attr_accessor:mony_rebate
definitialize(mony_rebate)
@mony_rebate=mony_rebate
end
defaccept_cash(money)
money*mony_rebate
end
end
#返利收费子类
classCashReturn<CashSuper
attr_accessor:mony_condition,:mony_return
definitialize(mony_condition,mony_return)
@mony_condition=mony_condition
@mony_return=mony_return
end
defaccept_cash(money)
ifmoney>mony_condition
money-(money/mony_condition)*mony_return
end
end
end
#现金收费工厂类
classCashFactory
defself.create_cash_accept(type)
casetype
when'正常收费'
CashNormal.new()
when'打8折'
CashRebate.new(0.8)
when'满三百减100'
CashReturn.new(300,100)
end
end
end
cash0=CashFactory.create_cash_accept('正常收费')
pcash0.accept_cash(700)
cash1=CashFactory.create_cash_accept('打8折')
pcash1.accept_cash(700)
cash2=CashFactory.create_cash_accept('满三百减100')
pcash2.accept_cash(700)
做到了自定义折扣比例和满减的数量。
存在的问题：
增加活动的种类时，打五折，满五百减二百，需要在工厂类中添加分支结构。
活动是多种多样的，也有可能增加积分活动，满100加10积分，积分一定可以领取活动奖品，这时就要增加一个子类。
但是每次增加活动的时候，都要去修改工厂类，是很糟糕的处理方式，面对算法有改动时，应该有更好的办法。
2.策略模式
CashSuper和子类都是不变的，增加以下内容：
classCashContext attr_accessor:cs definitialize(c_super) @cs=c_super end defresult(money) cs.accept_cash(money) end end type='打8折' cs=casetype when'正常收费' CashContext.new(CashNormal.new()) when'打8折' CashContext.new(CashRebate.new(0.8)) when'满三百减100' CashContext.new(CashReturn.new(300,100)) end pcs.result(700)
CashContext类对不同的CashSuper子类进行了封装，会返回对应的result。也就是对不同的算法进行了封装，无论算法如何变化。都可以使用result得到结果。
不过，目前有一个问题，使用者需要去做判断，来选择使用哪个算法。可以和简单工场类结合。
3.策略和简单工场结合
classCashContext
attr_accessor:cs
definitialize(type)
casetype
when'正常收费'
@cs=CashNormal.new()
when'打8折'
@cs=CashRebate.new(0.8)
when'满三百减100'
@cs=CashReturn.new(300,100)
end
end
defresult(money)
cs.accept_cash(money)
end
end
cs=CashContext.new('打8折')
pcs.result(700)
CashContext中实例化了不同的子类。（简单工厂）
将子类选择的过程转移到了内部，封装了算法（策略模式）。
调用者使用更简单，传入参数（活动类型，原价），即可得到最终的结果。
这里使用者只需要知道一个类（CashContext）就可以了，而简单工场需要知道两个类（CashFactory的accept_cash方法和CashFactory），也就是说封装的更彻底。