政策模式

政策模式屬于對象的行為模式。其用意是針對一組算法，将每一個算法封裝到具有共同接口的獨立的類中，進而使得它們可以互相替換。政策模式使得算法可以在不影響到用戶端的情況下發生變化。

政策模式是對算法的包裝，是把使用算法的責任和算法本身分割開來，委派給不同的對象管理。政策模式通常把一個系列的算法包裝到一系列的政策類裡面，作為一個抽象政策類的子類。用一句話來說，就是：“準備一組算法，并将每一個算法封裝起來，使得它們可以互換”。下面就以一個示意性的實作講解政策模式執行個體的結構。

政策模式涉及到三個角色：

環境(context)角色：持有一個strategy的引用。

抽象政策(strategy)角色：這是一個抽象角色，通常由一個接口或抽象類實作。此角色給出所有的具體政策類所需的接口。

具體政策(concretestrategy)角色：包裝了相關的算法或行為。

uml圖

 政策模式的主要優點有：

政策類之間可以自由切換，由于政策類實作自同一個抽象，是以他們之間可以自由切換。

易于擴充，增加一個新的政策對政策模式來說非常容易，基本上可以在不改變原有代碼的基礎上進行擴充。

避免使用多重條件，如果不使用政策模式，對于所有的算法，必須使用條件語句進行連接配接，通過條件判斷來決定使用哪一種算法，在上一篇文章中我們已經提到，使用多重條件判斷是非常不容易維護的。

       政策模式的缺點主要有兩個：

維護各個政策類會給開發帶來額外開銷，可能大家在這方面都有經驗：一般來說，政策類的數量超過5個，就比較令人頭疼了。

必須對用戶端（調用者）暴露所有的政策類，因為使用哪種政策是由用戶端來決定的，是以，用戶端應該知道有什麼政策，并且了解各種政策之間的差別，否則，後果很嚴重。例如，有一個排序算法的政策模式，提供了快速排序、冒泡排序、選擇排序這三種算法，用戶端在使用這些算法之前，是不是先要明白這三種算法的适用情況？再比如，用戶端要使用一個容器，有連結清單實作的，也有數組實作的，用戶端是不是也要明白連結清單和數組有什麼差別？就這一點來說是有悖于迪米特法則的。

假設現在要設計一個販賣各類書籍的電子商務網站的購物車系統。一個最簡單的情況就是把所有貨品的單價乘上數量，但是實際情況肯定比這要複雜。比如，本網站可能對所有的進階會員提供每本20%的促銷折扣；對中級會員提供每本10%的促銷折扣；對初級會員沒有折扣。

轉換為uml圖如下

抽象折扣類

初級會員折扣類

中級會員折扣類

進階會員折扣類

價格管理類

測試

1）政策模式是一個比較容易了解和使用的設計模式，政策模式是對算法的封裝，它把算法的責任和算法本身分割開，委派給不同的對象管理。政策模式通常把一個系列的算法封裝到一系列的政策類裡面，作為一個抽象政策類的子類。用一句話來說，就是“準備一組算法，并将每一個算法封裝起來，使得它們可以互換”。

2）在政策模式中，應當由用戶端自己決定在什麼情況下使用什麼具體政策角色。2）

3）政策模式僅僅封裝算法，提供新算法插入到已有系統中，以及老算法從系統中“退休”的友善，政策模式并不決定在何時使用何種算法，算法的選擇由用戶端來決定。這在一定程度上提高了系統的靈活性，但是用戶端需要了解所有具體政策類之間的差別，以便選擇合适的算法，這也是政策模式的缺點之一，在一定程度上增加了用戶端的使用難度。