策略模式 雖然我本人比較討厭一些很官方的術語定義,因為我經常弄不明白有些定義講了個啥,但是為了讓這篇博文顯得不那麼輕浮,所以我也就不能免俗的先將設計模式之策略模式的定義首先丟到各位看官面前。 策略模式定義了演算法族,分別封裝起來,讓他們之間可以互相替換,此模式讓演算法的變化獨立於使用演算法的客戶。 第一眼 ...
策略模式
聲明:本文為原創,如有轉載請註明轉載與原作者並提供原文鏈接,僅為學習交流,本人才識短淺,如有錯誤,敬請指正
雖然我本人比較討厭一些很官方的術語定義,因為我經常弄不明白有些定義講了個啥,但是為了讓這篇博文顯得不那麼輕浮,所以我也就不能免俗的先將設計模式之策略模式的定義首先丟到各位看官面前。
策略模式定義了演算法族,分別封裝起來,讓他們之間可以互相替換,此模式讓演算法的變化獨立於使用演算法的客戶。
第一眼這個定義看上去,難免會讓人心生膽怯,又是演算法族,又是封裝,又是替換,似乎很複雜的樣子,但是實際上,很好理解,不信,我們來一起看一場非常激烈的籃球比賽吧,相信看完這場比賽之後你就能大致掌握這個設計模式了。
PS:有人肯定要問了,為啥沒有個UML圖呢,其他人說設計模式都會咣當扔個UML圖上來,你咋沒有呢,是不是偷工減料,其實啊,真不是,在於我這個人呢,比較喜歡直接擼代碼看代碼,也沒有說看UML圖理解一個設計模式的,並不說UML圖不重要,只是策略模式的UML圖在網上一搜一大把,我還是不要當搬運工,複製粘貼了吧。
歡迎大家來到NBA賽場,今天的比賽呢,雙方分別是湖人和騎士,科比與詹姆斯的宿命對決,作為籃球運動員,在場上,最重要的兩件事是啥呢,沒錯,就是“投籃”和“傳球”,投籃是為了得分,傳球是為了更輕鬆的投籃得分,投籃有很多種方式,後仰投籃,三分遠投,急停跳投,傳球包括擊地傳球,不看人傳球等,而在Java的設計模式中,我們可以把這些統統定義成“方法”。
我們首先抽象出來一個投籃相關的介面,它包含了一個方法:shoot(),即投籃
public interface ShootStrategy { public void shoot(); }
同樣的,我們抽象出來一個傳球相關的介面,它包含了一個方法:pass(),即傳球
public interface PassStrategy { public void pass(); }
那麼這兩個介面有什麼用呢,回到策略模式的定義,註意“演算法族”這三個字,什麼是演算法族,如果後仰投籃是一個演算法,三分遠投是一個演算法,急停跳投也是一個演算法,我們就會發現他們的共同點是,他們都是投籃的演算法,也就是說他們都是投籃的演算法族,同理,擊地傳球與不看人傳球也是傳球的演算法族,而後策略模式的定義說要分別封裝他們,提到封裝大家想到了什麼呢,類!
接下來我們嘗試封裝一下後仰投籃演算法和三分遠投演算法
public class BackwardShoot implements ShootStrategy { @Override public void shoot() { System.out.println("標誌性的後仰跳投"); } }
封裝後仰跳投演算法,代碼很簡單,因為我們不希望演算法的邏輯干擾到我們著眼於真正的重點——策略模式。
public class ThreeShoot implements ShootStrategy { @Override public void shoot() { System.out.println("神準的三分"); } }
封裝三分遠投演算法。
同樣的,我們也封裝一下傳球的演算法,畢竟籃球離不開傳球(科比:傳球,傳球是什麼意思,誤~)
public class DropPass implements PassStrategy { @Override public void pass() { System.out.println("詭異的擊地傳球"); } }
封裝擊地傳球演算法
public class NoLookPass implements PassStrategy { @Override public void pass() { System.out.println("一記精彩的不看人傳球"); } }
封裝不看人傳球演算法
好了,現在我們所有的策略都準備好了(原諒我這裡直接使用了策略,不用驚嚇,我們剛剛已經完成了策略模式最重要的部分),就差我們的運動員上場了。
我們首先定義一個籃球運動員的類。
public class BasketballPlayer { private String name; private ShootStrategy shootStrategy; private PassStrategy passStrategy; public void shoot(){ System.out.println("------" + name + "------"); shootStrategy.shoot(); } public void pass(){ System.out.println("------" + name + "------"); passStrategy.pass(); } public void setShootStrategy(ShootStrategy shootStrategy) { this.shootStrategy = shootStrategy; } public void setPassStrategy(PassStrategy passStrategy) { this.passStrategy = passStrategy; } public void selfIntroduction(){ System.out.println("我是個籃球運動員"); } public void setName(String name) { this.name = name; } }
看一下這段代碼,我定義了三個變數,name,表示運動員的名字,然後是我自己定義的投籃介面以及傳球介面,這倆乾乾巴巴,麻麻賴賴的介面放這裡有啥用呢,盤他,我們往下看,我們會發現,籃球運動員的投籃,使用的是我們投籃介面里的shoot()方法實現,而傳球呢,使用的是我們傳球介面里的pass()方法實現,有人就會想了,我這倆介面都沒方法體,調用個毛啊,稍安勿躁,繼續往下看,下麵是兩個平平無奇的setter方法,然而,奧秘就是在這裡,這個奧秘,我們一般叫他“解耦”,通過使用Java的介面回調,我們可以將任意對象傳入這個類中供這個類使用,只要這個類實現了對應的介面即可,在這裡就是投籃介面與傳球介面,然後我們就會發現,剛纔我們實現的後仰投籃,三分遠投等,這裡統統受用!
說了之久,我們的大明星怎麼還沒露面呢,繼續
科比是一名(is-a)籃球運動員,所以
public class Kobe extends BasketballPlayer { @Override public void selfIntroduction(){ System.out.println("我的名字是科比"); } }
詹姆斯是一名(is-a)籃球運動員,所以
public class James extends BasketballPlayer { @Override public void selfIntroduction(){ System.out.println("我叫詹姆斯"); } }
註意,雖然兩個類代碼比較少,但是不要忘了,由於他倆繼承了籃球運動員類,所以籃球運動員里的那些方法,他們也都擁有。
好啦,現在萬事俱備,讓我們開始這一場激動人心的比賽吧
public class LakerVsCavalier { public static void main(String[] args) { Kobe kobe = new Kobe(); kobe.selfIntroduction(); kobe.setName("科比"); James james = new James(); james.selfIntroduction(); james.setName("詹姆斯"); kobe.setPassStrategy(new NoLookPass()); kobe.setShootStrategy(new BackwardShoot()); kobe.pass(); kobe.shoot(); james.setPassStrategy(new DropPass()); james.setShootStrategy(new ThreeShoot()); james.pass(); james.shoot(); kobe.setPassStrategy(new DropPass()); kobe.setShootStrategy(new ThreeShoot()); kobe.pass(); kobe.shoot(); james.setPassStrategy(new NoLookPass()); james.setShootStrategy(new BackwardShoot()); james.pass(); james.shoot(); } }
雖然代碼看起來很簡單,只是讓科比與詹姆斯兩個對象shoot()與pass()而已,然而事情其實並沒有那麼簡單,回顧策略模式的定義,“讓它們之間可以互相替換”,這就是問題的關鍵,我們為同一個對象設置了不同的演算法,科比可以先設置傳球策略為不看人傳球,設置投籃策略為後仰跳投,然後此封裝的演算法就會被科比對象中的pass()和shoot()方法調用,原因上文已述,然後,我們可以重新為科比對象設置不同的演算法,我們把傳球策略為擊地傳球,投籃策略設置為三分遠投,然後科比再次傳球(調用pass方法),就變成了擊地傳球,再次投籃(調用shoot方法),就變成了三分遠投,詹姆斯對象同理。
我們來看一下執行結果
一切皆如我們所料。
至此,我們也就能理解策略模式定義的最後一句:此模式讓演算法的變化獨立於使用演算法的客戶。
更重要的一點是,通過策略模式,我們真正的將易於變化的部分抽出來,使代碼對修改關閉,對擴展開放,假設我們要添加一個新的策略——急停跳投,我們只需要通過實現投籃介面的方式新建一個急停跳投策略,然後把他set進科比,詹姆斯這種使用演算法的對象即可,完全不用修改已有的調用演算法的代碼!
有興趣的可以自己去實現看看哦
今天的籃球比賽轉播到此結束,我是設計模式評論員JR,我們下次再見。