什麼是政策模式
在前面的博文中，小編主要向小夥伴介紹了組合模式，今天這篇博文，我們繼續來學習設計模式的相關知識，今天和小夥伴們見面的是政策模式，政策模式英文名字叫Strategy，政策模式屬于行為模式的一種，她對一系列的算法加以封裝，為所有算法定義一個抽象的算法接口，并通過繼承該抽象算法接口對所有的算法加以封裝和實作，具體的算法選擇交由用戶端決定，政策模式主要用來平滑的處理算法的切換。
政策模式結構圖
我們來看一下政策的結構圖，如下所示：
對上述結構圖進行簡單的解釋說明：
a、将所有的算法都抽象成了Strategy，可以将算法分離出來并且進行更換。
b、Context 中含有對Strategy的引用。
c、通過contextInterface()，進行對算法的使用。
從上面的結構圖中，可以看出這些算法完成的都是相同的工作，隻是實作不同，它可以以相同的方式調用所有的算法，減少各種算法類與使用算法類之間的耦合。換句話說，政策模式并不将算法固定在具體的某個類中，而是将算法獨立出來，可根據需要替換算法。例如:Context中含有對 Straategy的引用。這裡還用到了依賴倒轉和裡斯代換原則，即Context依賴于抽象，而沒有依賴具體的子類，并且，子類可以替換父類。
政策模式簡單應用demo
接着，我們通過一個簡單的demo來了解一下政策模式是如何在實際中加以應用的，建立java項目Strategy，建立類MainClass，建立接口Strategy，編寫接口裡面的代碼部分，如下所示：
建立類MD5Strategy，實作接口Strategy，編寫相關代碼，如下所示：
建立類MDSStrategy，實作接口Strategy，編寫相關代碼，如下所示：
如果我們不使用政策模式，我們會在MainClass裡面如何編寫代碼呢？如下所示：
運作如下所示：
如果要執行MDSS的方法，我們可以對MainClass中的代碼部分進行修改，如下所示：
運作效果如下所示：
通過這種方式，可以實作動态的轉變，我們隻需要在用戶端進行改變即可，但是這個不符合政策模式，通過結構圖，我們可以看到有一個Context，可以了解成是一個工廠，建立Context類，并編寫相關代碼，如下所示：
編寫用戶端的代碼，如下所示：
執行MDSS，修改用戶端代碼如下所示：
通過這兩種方式的實作，經過對比我們可以發現，我們直接通過Context進行調用，我們可以把Strategy看成是一個抽象的接口，我們再來舉一個簡單的例子，幫助我們進一步加深對政策模式的了解，建立包Strategy，建立類MainClass，建立接口Strategy，編寫相關代碼如下所示：
建立類StrategyA實作Strategy，編寫相關代碼，如下所示：
建立類Context，編寫相關代碼，如下所示：
建立MainClass，編寫相關代碼，如下所示：
這個時候，商家改變政策，不打八折了，這個時候改成滿200返50，我們該如何實作呢？建立類StrategyB，實作Strategy，編寫相關代碼，如下所示：
編寫MainClass中的代碼部分，如下所示：
這樣，我們直接實作接口，寫一個方法就可以了，接着，我們來看一下政策模式的優缺點：
優點：
a、政策模式提供了管理相關的算法族的辦法，政策類的等級結構定義了一個算法或行為族，恰當使用繼承可以公共的代碼移到父類裡面，進而避免重複的代碼。
b、政策模式提供了可以替換繼承關系的辦法，繼承可以處理多種算法和行為，如果不使用政策模式，那麼使用算法或行為的環境類就可能會有一些子類，每一個子類提供一個不同的算法和行為，但是，這樣一來算法或行為的使用者就和算法或行為本身混在一起，決定使用哪一種算法或采取哪一種行為的邏輯就和算法或行為的邏輯混合在一起，進而不可能再單獨演化，繼承使得動态改變算法或行為變得不可能。
c、使用政策模式可以避免使用多重條件轉移語句，多重轉移語句不易維護，他把采用哪一種算法或采取哪一種行為的邏輯與算法或行為的邏輯混合在一起，統統列在一個多重轉移語句裡面，比使用繼承的辦法還要原始和落後。
缺點：
a、用戶端必須知道所有的政策類，并執行決定使用哪一個政策類，這就意味着用戶端必須了解這些算法的差別，以便适時選擇恰當的算法類，換言之，政策模式隻适用于用戶端知道所有的算法或行為的情況。
b、政策模式造成很多的政策類，有時候可以通過把依賴于環境的狀态儲存到用戶端裡面，而将政策類設計成可共享的，這樣政策類執行個體可以被不同用戶端使用，換言之，可以使用享元模式來減少對象的數量。
小編寄語：該博文小編主要簡單的介紹了政策模式，分别從什麼是政策模式、政策模式的結構圖、政策模式簡單應用demo、政策模式的優缺點四個方面對政策模式進行了簡單的介紹，政策模式是一個比較容易了解和使用的設計模式，政策模式是對算法的封裝，它把算法的責任和算法本身分割開，委派給不同的對象管理。政策模式通常把一個系列的算法封裝到一系列的政策類裡面，作為一個抽象政策類的子類。用一句話來說，就是“準備一組算法，并将每一個算法封裝起來，使得它們可以互換”。在政策模式中，應當由用戶端自己決定在什麼情況下使用什麼具體政策角色。政策模式僅僅封裝算法，提供新算法插入到已有系統中，以及老算法從系統中“退休”的友善，政策模式并不決定在何時使用何種算法，算法的選擇由用戶端來決定。這在一定程度上提高了系統的靈活性，但是用戶端需要了解所有具體政策類之間的差別，以便選擇合适的算法，這也是政策模式的缺點之一，在一定程度上增加了用戶端的使用難度。