Design Pattern_Skill_2_策略模式(Strategy Pattern)_要去打仗可能用刀也可能用手榴彈就都帶著吧
這次來探討策略模式
一時想不到捨麼好的開場.....
我們用一個遊戲場景來描述好了
你在一個遊戲中選擇了一個戰士角色然後你會在不同情況去更換武器裝備
這個時候腦海中好像浮現出了一連串的if else if ...else if....
程式碼
若於後期又有其他武器擴充....
那你寫好的程式又要改一些東西
不過客戶需求是否有改變呢? 其實是在合理範圍中做修改
因此要想一些比較好的設計方案利於後續的擴充....
而可以改變一要有捨麼就寫捨麼的寫程式習慣......
所以我們可以將客戶需求往未來做延伸考量
當客戶目前只提說想要
槍、手榴彈、刀...等三樣武器時
應該想到之後可能還會有其他類似弓、長槍之類的武器擴充
那就可以把武器整個抽象概念拉出來訂製一個基底(Base)規格(Base Class)
因為我們不確定未來還有捨麼規格變化或添加
當戰士需要用槍來做攻擊時
就在內部呼叫槍的物件
透過呼叫fighting間接去掉用使用槍來戰鬥的策略
但這麼設計會存有捨麼問題??
這樣有無符合開閉原則(對擴充開放,對修改封閉)嗎?
封閉 --> No!!!! 戰士的class很容易需要改變!!
其實刀、手榴彈、槍這些武器對於戰士而言通通都是一種戰鬥策略
因此他根本不care到底具體使用哪種因為他可隨時抽換!!!!
策略模式(Strategy Pattern)
代表著將一系列演算過程或流程封裝在一起且使它們可以相互替換
讓算法獨立於使用它的用戶(物件)而獨立去做變化
通常具備三種角色來應付所謂的策略模式
(1)抽象策略類(介面) (Strategy ):定義所有支援特定策略算法的介面。
(2)具體策略類(Concrete Strategy):藉由Strategy介面來實作具體算法
(3)環境類(Context)(策略類擁有者):內部維護一個Strategy物件的參考。
可定義一介面來讓Strategy訪問其當中資料。
應用環節:
比方像是在設計一套商場收銀系統各種商品有不同種促銷方案
依照不同時段(中秋、過年)有滿多少打幾折等等
會一直不停變換
解決方案:
Step1.定義抽象策略類或介面
Step2.實現具體策略類中定義之方法(針對不同實作該抽象類(介面)的類別)
Step3.定義環境類
Step1.定義抽象策略類或介面
Step2.實現具體策略類中定義之方法(針對不同實作該抽象類(介面)的類別)
Step3.定義環境類(策略擁有者)
在此對應的就是戰士的class
Main主程式中的應用測試
在此針對策略擁有者類(戰士)
我們若不想一直去實體化則可以直接改寫成一個get...set...方式來去做設定
最終實作結果:
Reference link:
https://itw01.com/AFSEK9U.html
https://skyyen999.gitbooks.io/-study-design-pattern-in-java/content/strategy.html
留言
張貼留言