欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

实例解析Ruby设计模式编程中Strategy策略模式的使用

程序员文章站 2022-06-24 11:24:20
今天你的leader兴致冲冲地找到你,希望你可以帮他一个小忙,他现在急着要去开会。要帮什么忙呢?你很好奇。 他对你说,当前你们项目的数据库中有一张用户信息表,里面存放了很...

今天你的leader兴致冲冲地找到你,希望你可以帮他一个小忙,他现在急着要去开会。要帮什么忙呢?你很好奇。
他对你说,当前你们项目的数据库中有一张用户信息表,里面存放了很用户的数据,现在需要完成一个选择性查询用户信息的功能。他说会传递给你一个包含许多用户名的数组,你需要根据这些用户名把他们相应的数据都给查出来。
这个功能很简单的嘛,你爽快地答应了。由于你们项目使用的是mysql数据库,你很快地写出了如下代码:

require 'mysql' 
 
class queryutil 
  def find_user_info usernames 
    @db = mysql.real_connect("localhost","root","123456","test",3306); 
    sql = "select * from user_info where " 
    usernames.each do |user| 
      sql << "username = '" 
      sql << user 
      sql << "' or " 
    end 
    puts sql 
    result = @db.query(sql); 
    result.each_hash do |row| 
      #处理从数据库读出来的数据 
    end 
    #后面应将读到的数据组装成对象返回,这里略去 
  ensure 
    @db.close 
  end 
end 

这里根据传入的用户名数组拼装了sql语句,然后去数据库中查找相应的行。为了方面调试,你还将拼装好的sql语句打印了出来。
然后,你写了如下代码来测试这个方法:

qutil = queryutil.new 
qutil.find_user_info ["tom", "jim", "anna"] 

现在运行一下测试代码,你发现程序出错了。于是你立刻去检查了一下打印的sql语句,果然发现了问题。

select * from user_info where username = 'tom' or username = 'jim' or username = 'anna' or  
拼装出来的sql语句在最后多加了一个 or 关键字!因为for循环执行到最后一条数据时不应该再加上or,可是代码很笨地给最后一条数据也加了or关键字,导致sql语句语法出错了。
这可怎么办呢?
有了!你灵光一闪,想出了一个解决办法。等sql语句拼装完成后,截取到最后一个or之前的位置不就好了么。于是你将代码改成如下所示:

require 'mysql' 
 
class queryutil 
  def find_user_info usernames 
    @db = mysql.real_connect("localhost","root","123456","test",3306); 
    sql = "select * from user_info where " 
    usernames.each do |user| 
      sql << "username = '" 
      sql << user 
      sql << "' or " 
    end 
    sql = sql[0 .. -" or ".length] 
    puts sql 
    result = @db.query(sql); 
    result.each_hash do |row| 
      #处理从数据库读出来的数据 
    end 
    #后面应将读到的数据组装成对象返回,这里略去 
  ensure 
    @db.close 
  end 
end 

使用string的截取子字符串方法,只取到最后一个or之前的部分,这样再运行测试代码,一切就正常了,打印的sql语句如下所示:

select * from user_info where username = 'tom' or username = 'jim' or username = 'anna' 

好了,完工!你自信满满。
你的leader开完会后,过来看了下你的成果。总体来说,他还挺满意,但对于你使用的sql语句拼装算法,他总是感觉有些不对劲,可是又说不上哪里不好。于是他告诉了你另一种拼装sql语句的算法,让你加入到代码中,但是之前的那种算法也不要删除,先保留着再说,然后他又很忙似的跑开了。于是,你把他刚刚教你的算法加了进去,代码如下所示:

require 'mysql' 
 
class queryutil 
  def find_user_info(usernames, strategy) 
    @db = mysql.real_connect("localhost","root","123456","test",3306); 
    sql = "select * from user_info where " 
    if strategy == 1 
      usernames.each do |user| 
        sql << "username = '" 
        sql << user 
        sql << "' or " 
      end 
      sql = sql[0 .. -" or ".length] 
    elsif strategy == 2 
      need_or = false 
      usernames.each do |user| 
        sql << " or " if need_or 
        sql << "username = '" 
        sql << user 
        sql << "'" 
        need_or = true 
      end 
    end 
    puts sql 
    result = @db.query(sql); 
    result.each_hash do |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方法,这个方法就是简单的抛出了一个异常:

class strategy 
  def get_sql usernames 
    raise "you should override this method in subclass." 
  end 
end 

然后定义两个子类都继承上述父类,并将两种拼装sql语句的算法分别加入两个子类中:

class strategy1 
  def get_sql usernames 
    sql = "select * from user_info where " 
    usernames.each do |user| 
      sql << "username = '" 
      sql << user 
      sql << "' or " 
    end 
    sql = sql[0 .. -" or ".length] 
  end 
end 

class strategy2 
  def get_sql usernames 
    sql = "select * from user_info where " 
    need_or = false 
    usernames.each do |user| 
      sql << " or " if need_or 
      sql << "username = '" 
      sql << user 
      sql << "'" 
      need_or = true 
    end 
  end 
end 

然后在queryutil的find_user_info方法中调用strategy的get_sql方法就可以获得拼装好的sql语句,代码如下所示:

require 'mysql' 
 
class queryutil 
  def find_user_info(usernames, strategy) 
    @db = mysql.real_connect("localhost","root","123456","test",3306); 
    sql = strategy.get_sql(usernames) 
    puts sql 
    result = @db.query(sql); 
    result.each_hash do |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 * from user_info where username = 'tom' or username = 'jim' or username = 'anna' 
select * from user_info where username = 'jac' or username = 'joe' or username = 'rose' 

使用策略模式修改之后,代码的可读性和扩展性都有了很大的提高,即使以后还需要添加新的算法,你也是手到擒来了!

策略模式和简单工厂模式结合的实例

需求:

商场收银软件,根据客户购买物品的单价和数量,计算费用,会有促销活动,打八折,满三百减一百之类的。

1.使用工厂模式

# -*- encoding: utf-8 -*-

#现金收费抽象类
class cashsuper
  def accept_cash(money)
  end
end

#正常收费子类
class cashnormal < cashsuper
  def accept_cash(money)
    money
  end
end

#打折收费子类
class cashrebate < cashsuper
  attr_accessor :mony_rebate
  
  def initialize(mony_rebate)
    @mony_rebate = mony_rebate
  end

  def accept_cash(money)
    money * mony_rebate
  end
end

#返利收费子类
class cashreturn < cashsuper
  attr_accessor :mony_condition, :mony_return
  
  def initialize(mony_condition, mony_return)
    @mony_condition = mony_condition
    @mony_return = mony_return
  end

  def accept_cash(money)
    if money > mony_condition
      money - (money/mony_condition) * mony_return
    end
  end
end

#现金收费工厂类
class cashfactory
  def self.create_cash_accept(type)
    case type
    when '正常收费'
      cashnormal.new()
    when '打8折'
      cashrebate.new(0.8)
    when '满三百减100'
      cashreturn.new(300,100)
    end
  end
end

cash0 = cashfactory.create_cash_accept('正常收费')
p cash0.accept_cash(700)

cash1 = cashfactory.create_cash_accept('打8折')
p cash1.accept_cash(700)

cash2 = cashfactory.create_cash_accept('满三百减100')
p cash2.accept_cash(700)

做到了自定义折扣比例和满减的数量。

存在的问题:

增加活动的种类时,打五折,满五百减二百,需要在工厂类中添加分支结构。

活动是多种多样的,也有可能增加积分活动,满100加10积分,积分一定可以领取活动奖品,这时就要增加一个子类。

但是每次增加活动的时候,都要去修改工厂类,是很糟糕的处理方式,面对算法有改动时,应该有更好的办法。

2.策略模式

cashsuper和子类都是不变的,增加以下内容:

class cashcontext
  
  attr_accessor :cs
  
  def initialize(c_super)
    @cs = c_super
  end
  
  def result(money)
    cs.accept_cash(money)
  end

end

type = '打8折'
cs=case type
  when '正常收费'
    cashcontext.new(cashnormal.new())
  when '打8折'
    cashcontext.new(cashrebate.new(0.8))
  when '满三百减100'
    cashcontext.new(cashreturn.new(300,100))
  end
p cs.result(700)

cashcontext类对不同的cashsuper子类进行了封装,会返回对应的result。也就是对不同的算法进行了封装,无论算法如何变化。都可以使用result得到结果。
不过,目前有一个问题,使用者需要去做判断,来选择使用哪个算法。可以和简单工场类结合。

3.策略和简单工场结合

class cashcontext
  
  attr_accessor :cs
  
  def initialize(type)
    case type
    when '正常收费'
      @cs = cashnormal.new()
    when '打8折'
      @cs = cashrebate.new(0.8)
    when '满三百减100'
      @cs = cashreturn.new(300,100)
    end
  end
  
  def result(money)
    cs.accept_cash(money)
  end

end

cs=cashcontext.new('打8折')

p cs.result(700)

cashcontext中实例化了不同的子类。(简单工厂)
将子类选择的过程转移到了内部,封装了算法(策略模式)。

调用者使用更简单,传入参数(活动类型,原价),即可得到最终的结果。
这里使用者只需要知道一个类(cashcontext)就可以了,而简单工场需要知道两个类(cashfactory的accept_cash方法和cashfactory),也就是说封装的更彻底。