截止目前而言設計模式的形成往兩個方向考慮：解耦性、可擴充套件性。

其實我們在日常生活中，也會根據事物的狀態做出選擇，比如收到朋友邀約的時候，我也會從工作完成度、休息情況等多重維度進行考量，根據我判斷的結果，做出相應的答覆和行為。

就比如在影片中所說，根據同學是哪位老師的熟人來判斷同學報名課程可以減免多少。

看到這裡，大家認為這就是一個簡單的條件邏輯判斷大家覺得這裡有什麼問題呢？

還是從我之前說的思路去想，能不能解耦！！

這個方法幹了幾件事？

兩件：判斷--->執行

如果我每次的判斷執行的業務都非常複雜這一個quate方法上百行都有可能，後期但凡出bug或者想做最佳化，這個程式碼的複雜度和冗餘度能給人整吐，可不可以把判斷跟執行分開來呢？

單個判斷所對應的執行變成方法。一個獨立的工具，一個方法只負責做對應的判斷需要做的一件事情，這樣我判斷後直接找其他人做，這個人本怎麼做與我無關，解耦完成！

到了這裡解耦我們看起來做的很好了。還記得我們之前還考慮的一個方向麼-----可擴充套件性。如果我想再增加的D判斷呢，或者減少呢？

其實這個解決判斷的問題，如果看過工廠方法模式一定會很熟悉我們是透過類替換了判斷，這樣，如果使用者向增加判斷，只需要增加一個實現規則介面的類就行了。

其實在我們這裡同理我們的整個A情況跟A行為會被封裝成一個類，然後方法只需要以這個類的物件作為引數，去執行這個物件要求去做的事（類似於諸葛亮交給趙雲的錦囊妙計）。

其實這個類只是執行方法外放成類，並沒有什麼太大特殊之處，只是引數從原來的int狀態引數變成int狀態引數對應的錦囊妙計，讓我們來看看這個錦囊是什麼。

當然那麼多錦囊肯定是需要一個總錦囊介面管理：

來看看上面的程式碼。我只需要選擇我目前的情況對應的執行錦囊我就能達到同樣的效果。如果我想多一個錦囊我就只需要自定義增加一個繼承Strategy的類就行了（這靈活性槓槓的）。

當然如果這個Price類之後需要一直用到策略，可以提升策略物件的生命週期，宣告它為全域性變數。

這其實是看業務需求做出的變數位置的改變，變成屬性的話，它會隨著price物件建立立即載入。

總結一下：

一個情況對應一個執行方法我直接把方法封裝起來，使用者自己根據情況，去放置對應的物件，物件會幫你做你預想的事。

其實看過鎧甲勇士或者假面騎士，可以把這個策略看成，主角根據對手選擇的元素塊，那個price可以看成變身器。不同的元素塊，賦予不同的變身後的行為特性。