之前的一段時間一直在學習設計模式相關知識，學習一段時間后發現，設計模式不能算是知識點，其僅僅是一種思想，我們應該在日常的開發設計中潛移默化的應用這種思想，而不是為了模式而模式。言歸正傳，今天我想來叨叨策略模式和狀態模式。
先看看他們的UML圖
兩個模式的UML圖基本上是相同的。
策略模式的Context含有一個Strategy的引用，將自身的功能委托給Strategy來完成。
將上面的UML圖中的Strategy接口改個名字為State，這就是狀態模式了，同樣Context也有一個State類型的引用，也將自己的部門功能委托給State來完成。
他們之間真正的區別在策略模式對Strategy的具體實現類有絕對的控制權，即Context要感知Strategy具體類型。而狀態模式，Context不感知State的具體實現，Context只需調用自己的方法，這個調用的方法會委托給State來完成，State會在相應的方法調用時，自動為Context設置狀態，而這個過程對Context來說是透明的，不被感知的。
設計模式五大設計原則：SOLID，S 單一職責，O 對修改關閉對擴展開放，L 里式替換，I 接口隔離，D 依賴倒置
1.這兩種模式沒有明確的遵循單一職責的原則
2.兩種模式都依賴的是上層接口，符合對修改關閉對擴展開放原則
3.顯然子類的實現類都可以替換Context中接口的引用的，符合里式替換
4.接口隔離暫未體現
5.依賴倒置目前我是沒看出來。工廠模式詮釋了依賴倒置，高層調用和底層對象的產生都依賴抽象，而非具體實現，我會在稍后的系列中提到。
再談兩種模式的使用，相對來說策略模式比狀態模式簡單一點。
- 策略模式的控制權在客戶端，業務邏輯能夠很好的剝離。而狀態模式需要我們對整個業務中的狀態進行抽象，並且需要對頂層State接口中的方法進行抽象。
- State的方法中需要對Context的狀態進行管理，這也增加了一定的復雜性。
PS：我更願意將Context中Strategy引用的成員變量理解為委托，在運行時可以動態的改變Strategy的實現類，這比繼承更加靈活。