上篇文章【大話設計模式】——簡單工廠模式告訴了我們乙個網咖收費工廠物件怎樣建立收費形式（白天收費、夜間收費）的例項。簡單工廠**中有非常多 case分支語句 ,假設我們還想填加收費的形式（比方會員收費啊，通宵收費啊），就須要修改工廠**，每次維護和擴充套件都要花費非常多時間，另外修改非常easy造成紕漏（比方之前的白天收費形式，非常可能由於修改從多收錢或者少收錢），所以簡單工廠模式非常不安全。
所以我們要把常常變化的**抽象出來，做到業務邏輯和介面邏輯分開，僅僅有這樣才幹更加easy做到維護和擴充套件。
發現問題，解決這個問題，人類就這樣一點一滴的進步著。
發現了簡單工廠的不好，策略模式就誕生啦，人類真的是非常睿智！
（呱唧呱唧）
以下大家熟悉一下策略模式的定義：
策略模式（strategy）:它定義了演算法家族，分別封裝起來。讓她們之間能夠互相替換。此模式讓演算法的變化。不會影響到使用演算法的客戶。
context（環境類）：須要使用concretestrategy的詳細演算法，維護乙個對strategy物件的引用，負責跟strategy之間的互動和資料傳遞。
strategy（抽象策略類）：定義全部支援的演算法的公共介面。
context使用這個介面來呼叫concretestrategy演算法。
concretestrategy（詳細策略類）：封裝了詳細的演算法和行為，繼承與strategy.
圖中含有兩種關係。聚合和繼承。
比方我們填飽肚子的方式。有幾個策略能夠考慮：吃水果、吃蔬菜、吃饅頭。
首先定義乙個抽象類吃，然後讓吃的形式：吃水果，吃蔬菜。吃饅頭繼承這個抽象吃類。再宣告乙個context類，用來配置吃的方法，維護乙個對strategy物件的引用。
using system;
using system.collections.generic;
using system.linq;
using system.text;
using system.threading.tasks;
}abstract class eatstrategy//抽象吃法類
class eatingfruit:eatstrategy //詳細吃法吃蘋果
}class eatingvegetables : eatstrategy//詳細吃法吃蔬菜
}class eatingsteambread : eatstrategy//詳細吃法吃饅頭
}class context//寫策略環境類
//上下文介面
public void contextinte***ce()//依據詳細的策略物件，呼叫其演算法的方法}}
個人理解：無論是吃水果還是吃蔬菜，異或是吃饅頭。都是為了填飽肚子。儘管形式不同，假設有的人挑食吃飯一定要吃菜加饅頭才肯吃，那假設沒有賣饅頭的，你就要**啦~
2）策略模式strategy類層次為context定義了一系列的可供重用的演算法和行為。
繼承有助於析取出這些演算法中的公共功能。
個人理解：把東西分類放置。使用的時候就更加easy找到。
3）簡化了單元測試，由於每乙個演算法都有自己的類，能夠通過自己的介面單獨測試。
個人理解：有單獨的類。就更easy滿足單一職責原則。這樣測試乙個功能，資料假設不正確，直接就能劃分出範圍。
比方值日分為掃地和擦桌子。安排小明拖地，小紅擦桌子。假設值完日了，地面還髒。那肯定就是小明幹的不好唄（當然排除搞破壞的可能）。
可是假設你讓兩個人幹活，又沒有分配任務，那好了，挨罰就兩個人一起做個伴吧！
4）演算法封裝在單獨的類中。能夠消除條件語句。為client減輕了壓力。
個人理解：領導者假設負責乙個非常龐大的project的話，那些瑣事會讓他侷限於細節，而失去了把控能力。
1）client必須知道全部的策略類，並自行決定使用哪個策略類。
2）strategy和context之間存在通訊開銷
3）假設詳細策略過多，會產生非常多的策略類，新增了維護的難度。
**即人生啊~
大話設計模式 策略模式
前言 做事情的時候我們需要動動腦來簡化自己完成任務的負擔，這就需要講究策略了，我們會根據自己所處的環境列出所有的可能條件，再從中挑選合適的方法來完成這件事。就像我們過年回家，我們可以選擇高鐵 普通火車 還可以選擇硬座 軟座 臥鋪，這都是我們回家的策略 買不到直達的還得轉戰好幾個火車站，策略的最終到達...
大話設計模式 策略模式
前言 做事情的時候我們需要動動腦來簡化自己完成任務的負擔，這就需要講究策略了，我們會根據自己所處的環境列出所有的可能條件，再從中挑選合適的方法來完成這件事。就像我們過年回家，我們可以選擇高鐵 普通火車 還可以選擇硬座 軟座 臥鋪，這都是我們回家的策略 買不到直達的還得轉戰好幾個火車站，策略的最終到達...
大話設計模式 策略模式
引用於 大話設計模式 第二章 策略模式 c 實現 策略模式介紹 簡單工廠模式只是解決物件的建立問題，而且由於工廠本身包括了所有的收費方式，商場可能經常性的更改打折額度和返利額度，每次維護或者擴充套件收費方式都要改動這個工廠，以致 需要重新編譯部署，這不是一種好方法。而且為了建立不同的物件產品使用了s...