團「模子」政策模式亂舞

周所周知，超市收銀系統都具有計費功能，那麼要你做乙個可以依據輸入的商品單位**和數量，以及計費方式進行計算的模組，你怎樣做？計費方式也就是打不打折，有沒有返利優惠等等。那麼我們先用簡單工廠模式去實現一下。

簡單工廠實現

using system;
using system.collections.generic;
using system.componentmodel;
using system.data;
using system.drawing;
using system.linq;
using system.text;
using system.threading.tasks;
using system.windows.forms;
namespace 商場收銀軟體
double total = 0.0d;
private void textbox1_textchanged(object sender, eventargs e)
private void label5_click(object sender, eventargs e)
private void form1_load(object sender, eventargs e)
);cbxtype .selectedindex =0;
}private void buttonok_click(object sender, eventargs e)
private void button2_click(object sender, eventargs e)
}//現金收費抽象類
abstract class cashsuper
//正常收費子類
class cashnormal : cashsuper
}//打折收費子類
class cashrebate : cashsuper
public override double acceptcash(double money)
}//返利收費子類
class cashreturn : cashsuper
public override double acceptcash(double money)
}//現金收費工廠類
class cashfactory
return cs;}}
}

我們看到，這樣的方案的特點就是將計費方式的例項化放到了工廠裡。從而在須要加入新的計費方式的時候，僅僅需在工廠裡加一下條件。完了再設計乙個對應的類就可以。

可是這樣做相同也破壞了開放—封閉原則，每一次的擴充套件都要大動干戈，實在是不好，不好。面對演算法的時常變動。怎樣應對？以下我們用還有一種方式試試：

策略模式實現

using system;
using system.collections.generic;
using system.componentmodel;
using system.data;
using system.drawing;
using system.linq;
using system.text;
using system.threading.tasks;
using system.windows.forms;
namespace 商場收銀軟體
double total = 0.0d;
private void textbox1_textchanged(object sender, eventargs e)
private void label5_click(object sender, eventargs e)
private void form1_load(object sender, eventargs e)
);cbxtype .selectedindex =0;
}private void buttonok_click(object sender, eventargs e)
double totalprices = 0d;
totalprices = cc.getresult(convert.todouble(txtprice.text) * convert.todouble(txtnum.text));
total = total + totalprices;
lbxlist.items.add("單位**：" + txtprice.text + "數量：" + txtnum.text + "計費方式：" + cbxtype.selecteditem + "合計：" + totalprices.tostring());
lblresult.text = total.tostring();
}private void button2_click(object sender, eventargs e)
}//現金收費抽象類
abstract class cashsuper
//正常收費子類
class cashnormal : cashsuper
}//打折收費子類
class cashrebate : cashsuper
public override double acceptcash(double money)
}//返利收費子類
class cashreturn : cashsuper
public override double acceptcash(double money)
}//現金收費工廠類
//class cashfactory
////        return cs;
//    }
//}//cashcontext類
class cashcontext
public double getresult(double money)
}}

對照兩個方案，我們能夠看到不同之處就是策略模式將工廠類撤了。取而代之的是cashcontext類，然而又將實現哪乙個演算法的推斷交給了client，這樣client承擔的責任又大了，不好。不好……

怎麼辦？要不將簡單工廠和策略模式混搭？試試看。對於他們的結合。僅僅需將cashcontext類改造一下就可以，例如以下：

//改造後的cashcontext類
class cashcontext
}public double getresult(double money)
}

這樣一來，client的**就要簡單的多了，簡單工廠模式須要讓client和兩個類cashsuper和cashfactory打交道，而策略模式與簡單工廠結合後的使用方法，client就僅僅需和cashcontext打交道就可完畢對應的功能，減少了耦合性。

我們再回過頭去看策略模式的定義：

策略模式：定義了演算法家族，分別封裝起來，讓它們之間能夠相互替代，此模式讓演算法的變化，不會影響到使用此演算法的客戶。

團「模子」政策模式亂舞

團購模式弊端漸現

團購模式因何衰敗

美團旅行訂單免費退改政策延至8月底

團「模子」政策模式亂舞

團購模式弊端漸現

團購模式因何衰敗

美團旅行訂單免費退改政策延至8月底

相關推薦