在軟件領域，設計模式作為一種經(jīng)典的開發(fā)實踐，往往需要我們深入去了解，而種設計模式的使用頻率是相對較高，下文是武林技術頻道小編為大家?guī)淼慕馕鯮uby設計模式編程中Strategy策略模式的實現(xiàn)實例，一起跟著小編的步伐來看看吧！
如下代碼：
ruby;">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| #處理從數(shù)據(jù)庫讀出來的數(shù)據(jù) end #后面應將讀到的數(shù)據(jù)組裝成對象返回，這里略去 ensure @db.close end end 這里根據(jù)傳入的用戶名數(shù)組拼裝了SQL語句，然后去數(shù)據(jù)庫中查找相應的行。為了方面調試，你還將拼裝好的SQL語句打印了出來。
然后，你寫了如下代碼來測試這個方法：
qUtil = QueryUtil.new qUtil.find_user_info ["Tom", "Jim", "Anna"]
現(xiàn)在運行一下測試代碼，你發(fā)現(xiàn)程序出錯了。于是你立刻去檢查了一下打印的SQL語句，果然發(fā)現(xiàn)了問題。
select * from user_info where username = 'Tom' or username = 'Jim' or username = 'Anna' or??
拼裝出來的SQL語句在最后多加了一個 or 關鍵字！因為for循環(huán)執(zhí)行到最后一條數(shù)據(jù)時不應該再加上or，可是代碼很笨地給最后一條數(shù)據(jù)也加了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| #處理從數(shù)據(jù)庫讀出來的數(shù)據(jù) end #后面應將讀到的數(shù)據(jù)組裝成對象返回，這里略去 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| #處理從數(shù)據(jù)庫讀出來的數(shù)據(jù) end #后面應將讀到的數(shù)據(jù)組裝成對象返回，這里略去 ensure @db.close end end 可以看到，你leader教你的拼裝算法，使用了一個布爾變量來控制是否需要加個or這個關鍵字，第一次執(zhí)行for循環(huán)的時候因為該布爾值為false，所以不會加上or，在循環(huán)的最后將布爾值賦值為true，這樣以后循環(huán)每次都會在頭部加上一個or關鍵字，由于使用了頭部添加or的方法，所以不用再擔心SQL語句的尾部會多出一個or來。然后你為了將兩個算法都保留，在find_user_info方法上加了一個參數(shù)，strategy值為1表示使用第一種算法，strategy值為2表示使用第二種算法。
這樣測試代碼也需要改成如下方式：
qUtil = QueryUtil.new qUtil.find_user_info(["Tom", "Jim", "Anna"], 2)
這里你通過參數(shù)指明了使用第二種算法來拼裝SQL語句，打印的結果和使用第一種算法是完全相同的。
你立刻把你的leader從百忙之中拖了過來，讓他檢驗一下你當前的成果，可是他還是一如既往的挑剔。
“你這樣寫的話，find_user_info這個方法的邏輯就太復雜了，非常不利于閱讀，也不利于將來的擴展，如果我還有第三第四種算法想加進去，這個方法還能看嗎？”? 你的leader指點你，遇到這種情況，就要使用策略模式來解決，策略模式的核心思想就是把算法提取出來放到一個獨立的對象中。
為了指點你，他不顧自己的百忙，開始教你如何使用策略模式進行優(yōu)化。
首先定義一個父類，父類中包含了一個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| #處理從數(shù)據(jù)庫讀出來的數(shù)據(jù) end #后面應將讀到的數(shù)據(jù)組裝成對象返回，這里略去 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'
使用策略模式修改之后，代碼的可讀性和擴展性都有了很大的提高，即使以后還需要添加新的算法，你也是手到擒來了！
策略模式和簡單工廠模式結合的實例
需求：
商場收銀軟件，根據(jù)客戶購買物品的單價和數(shù)量，計算費用，會有促銷活動，打八折，滿三百減一百之類的。
1.使用工廠模式
# -*- encoding: utf-8 -*-#現(xiàn)金收費抽象類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#現(xiàn)金收費工廠類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)做到了自定義折扣比例和滿減的數(shù)量。
存在的問題：
增加活動的種類時，打五折，滿五百減二百，需要在工廠類中添加分支結構。
活動是多種多樣的，也有可能增加積分活動，滿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中實例化了不同的子類。（簡單工廠）
將子類選擇的過程轉移到了內部，封裝了算法（策略模式）。
調用者使用更簡單，傳入?yún)?shù)（活動類型，原價），即可得到最終的結果。
這里使用者只需要知道一個類（CashContext）就可以了，而簡單工場需要知道兩個類（CashFactory的accept_cash方法和CashFactory），也就是說封裝的更徹底。
以上就是解析Ruby設計模式編程中Strategy策略模式的實現(xiàn)實例，現(xiàn)在你知道怎么操作了吧?要想學習專業(yè)的知識，請關注武林技術頻道，我們定為你的保駕護航。
新聞熱點
疑難解答
圖片精選
