最近在看《大話設計模式》，做一點總結總結吧。
之前也進行學習過設計模式，但是都是講該設計模式是什麼，包含哪些元素，再配合一點簡單的demo，了解很不深刻。最近又重新學一下。
簡單工廠模式
在這本書中由案例寫一個電腦引入，按照我們的思維就是根據題意寫出對應的需求，但是對于後面的維護這些考慮的就很少了，頂多把計算的過程封裝成一個函數（這是我目前思維），後面大鳥開始說我如果開始增加計算功能呢？例如增加計算一個數的平方根，你還要去修改原來計算的代碼，增加對應的操作。那每次變化都要對該類進行修改。這個時候就引入了簡單工廠模式。
建立一個抽象類為父類，裡面包含變量有num1，computation，num2，方法getResult()。
子類：加法類、減法類、乘類、除類、開方類。
如果再想增加計算操作，直接建立對應的子類即可。
感覺就是将抽象類父類是一個生産工廠，可以建立功能類似的各個類，每個類内部去進行具體的操作
政策模式
在本書中由案例寫一個商場計算商品金額的系統引入，我很自然想的很簡單，那就是商品總數*商品單價，之後再進行累加操作。（寫在一個類中，在封裝一個計算商品金額方法就行了）
大鳥後面說那現在商場進行活動促銷，滿300-100呢？
那我想的就是在計算商品金額的方法多加一個參數，計算的時候判斷一下是正常計算還是進行滿減計算，傳回最終使用者應該支付的金額。
大鳥後面說如果商場進行8折活動呢？以後可能還會有7、6折等活動？
如果這樣的話我每次都要去修改計算商品金額的方法。
但是這時突然想起了開放封閉原則，在需求增加時隻需要向系統中加入新的功能實作類，而原有的一切保持封閉不變的狀态，這就是基于抽象機制而實作的開放封閉式設計。
在本書中，使用簡單工廠+政策模式相結合： 建立了一個類A，類A裡面定義父類變量B，并且根據輸入的活動類型進行選擇合适的子類（正常收費、打折收費、返利收費）進行運算。
政策模式是用來封裝算法的，用它來封裝幾乎任何類型的規則，隻要在分析過程中聽到需要在不同時間應用不同的業務規則，就可以使用側羅模式來處理這種變化的可能性
單一職責原則
就一類而言，應該僅有一個引起它變化的原因。
軟體設計真正要做的内容，就是發現職責并把那些職責互相分離。如果你能夠想到多于一個的冬季去改變一個類，那麼這個類就是具體有多一個的職責，這個時候就應該考慮類的職責分離。