前言
政策模式是設計模式中的行為型模式，所謂行為型就是其主要使用在方法有很大靈活性的情況。而之前的工廠模式主要是對建立對象的優化，減少程式中使用new對象的次數。政策模式在java源碼中也是很常見的，比如我們要比較兩個對象的大小，既可以使用預設的comparable接口，也可以實作自定義的比較規則，即實作comparator接口。這兩種比較比較方法都是不同比較規則的展現，屬于不同的政策。政策模式從定義上是這麼說的：定義了算法家族，把這些不同的算法封裝起來，讓他們之間可以互相替換。進而使得算法的替換不會影響調用者的變化。光從字面上感覺還不是特别清晰，簡單來說就是要辦成一件事可以有不同的方法，這些方法都是屬于一個家族的，是以從本質上來講，這些方法是沒有差別的。因為外界調用的時候隻需要知道這個家族的代表是誰就可以了，其他的調用者并不需要關心。
問題背景
實作一個收銀軟體，輸入單價與數量計算總價格。商場的收費方式可能有多種而且還會随時改變。
編碼實踐一，使用簡單工廠模式實作
測試結果：
編碼實踐二，使用政策模式實作
測試結果2：
ok，現在使用兩種方法的測試結果是一緻的，那麼來看看兩種設計模式的差別。對比類<code>cashcontext</code>與<code>cashfactory</code>我們可以發現，政策模式封裝了一個cash對象，而這個對象是所有收費方法類的超類，那麼在計算最後的錢數的時候，cashcontext隻是建立了一個執行個體，使用了一個cashcontext類，而使用簡單工廠模式在計算的時候，使用了cashfactory和cash兩個類，那麼使用類的個數的多少又有什麼關系呢？在java中提倡依賴倒轉原則，意思就是要要面向抽象程式設計而不是面向細節程式設計。延伸來講就是，對外暴露的細節越少越好，因為對外暴露的細節越少，因需求變更而修改的代碼越少，同時這也是開放-封閉原則的展現，是以從這點講簡單工廠模式對外暴露的位元組大于政策模式，是以在面向抽象程式設計上更勝一籌。當然政策模式也有其不足，比如在構造函數中添加了邏輯判斷語句，，與使用構造函數的初衷不是很符合，是以建立一個單獨的方法或者類來單獨完成類執行個體化的工作會更好一些。注意到，前面的cashfactory類的createcashobject()方法正是用來建立cash對象的，是以可以把cashcontext構造函數建立cash對象的方法直接改為createcashobject()方法。這樣每一個類的調用關系又進一步解耦了。
最後，對政策模式做一個簡單的總結：
每個算法類封裝了不同的實作，但完成的是相同的工作。這樣就把算法實作類與使用算法類的類解耦
簡化了單元測試
對外部暴露了更少的實作細節，符合開放-封閉原則
當算法實作類不斷增加的時候，在context類中增加的switch分支會越來越多