執行個體解析Ruby設計模式編程中Strategy策略模式的使用_ruby專題

今天你的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)  endend#正常收費子類class CashNormal < CashSuper  def accept_cash(money)    money  endend#打折收費子類class CashRebate < CashSuper  attr_accessor :mony_rebate    def initialize(mony_rebate)    @mony_rebate = mony_rebate  end  def accept_cash(money)    money * mony_rebate  endend#返利收費子類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  endend#現金收費工廠類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  endendcash0 = 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)  endendtype = '打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))  endp 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)  endendcs=CashContext.new('打8折')p cs.result(700)

CashContext中執行個體化了不同的子類。（簡單工廠）
將子類選擇的過程轉移到了內部，封裝了演算法（策略模式）。

調用者使用更簡單，傳入參數（活動類型，原價），即可得到最終的結果。
這裡使用者只需要知道一個類（CashContext）就可以了，而簡單工場需要知道兩個類（CashFactory的accept_cash方法和CashFactory），也就是說封裝的更徹底。