面向对象编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类
我们在Martin编写的《代码整洁之道》中对类的看法，类应该短小（长度不应该容纳一个if嵌套语句，20行封顶），而且只做一件事，做好这件事。强调的是简洁和优雅，但是不没说类越多越好。
这里我们可以明白我们应该用什么态度来看待和创建类，对我们的工程很重要。
策略模式的定义：
策略模式UML:
主要的东西还是Context的配置，传入具体的策略，然后返回出对应策略的的结果。
下面是收费策略的一个事例
//收费策略Context class CashContext { //声明一个现金收费父类对象 private CashSuper cs; //设置策略行为，参数为具体的现金收费子类（正常，打折或返利） public CashContext(CashSuper csuper) { this.cs = csuper; } //得到现金促销计算结果（利用了多态机制，不同的策略行为导致不同的结果） public double GetResult(double money) { return cs.acceptCash(money); } }
简单工厂与策略模式的结合是比较常见的。
简单工厂与策略模式结合事例（把客户端的switch给封装了，封装了变化的体现）
View Code //现金收取工厂 class CashContext { CashSuper cs = null ; //根据条件返回相应的对象 public CashContext(string type) { switch (type) { case "正常收费" : CashNormal cs0 = new CashNormal(); cs = cs0; break; case "满300返100" : CashReturn cr1 = new CashReturn( "300", "100" ); cs = cr1; break; case "打8折" : CashRebate cr2 = new CashRebate( "0.8"); cs = cr2; break; } } public double GetResult(double money) { return cs.acceptCash(money); } }
但是单是试用策略模式客户端如下：
对比一下可以知道后则只暴露了一个配置类Content而前者必须要客户端知道除了配置类其他的类，这样前者耦合性更低。
后则也把判断从客户端的判断条件给移除了，这样客户端判断压力减小了。
在定义上该模式是封装算法的，但是我几个人建议学习设计模式千万不要因为模式而模式，要因需求和设计而模式。因此
只要是不同时间要应用不同的业务那么这时候就该考虑策略模式了 。
总结：
策略模式与简单工厂的区别：
主要就是用Content上下文配置，客户端通过条件判断传递一个事例，然后实例化对应对像，
加上一个GetResult方法算出结果，客户端调用该方法返回结果得到值。这里对算法进行了封装
--------------------------------------------------------------------------------------------------------------
而简单工厂就是客户端只需要传递一个判断标识，然后工厂根据标识做出判断应该返回什么事例，
客户端拿到返回事例对象，通过调用该对象得到返回结果。这里对判断后置了减少了客户端判断压力
策略模式与简单工厂策略模式区别：
就是对前者优点的结合。
既封装了算法也减少了客户端判断压力
---------------------------------------------------------------------------------------------------------------
到此为止如果需求变动（增加一种算法）那么我们还是需要修改switch 条件
增加一个具体的算法类。
那么该如何让其不改动代码呢？对就是反射
我们以一种数据驱动的形式来处理这个问题，下拉框内存我们通过读取配置文件获取
客户端只需要传入类名和需要的参数即可如下：
View CodeDataSet ds;//用于存放配置文件信息 double total = 0.0d;//用于总计 private void Form1_Load(object sender, EventArgs e) { //读配置文件 ds = new DataSet(); ds.ReadXml(Application.StartupPath + "\\CashAcceptType.xml"); //将读取到的记录绑定到下拉列表框中 foreach (DataRowView dr in ds.Tables[0].DefaultView) { cbxType.Items.Add(dr["name"].ToString()); } cbxType.SelectedIndex = 0; } private void btnOk_Click(object sender, EventArgs e) { CashContext cc = new CashContext(); //根据用户的选项，查询用户选择项的相关行 DataRow dr = ((DataRow[])ds.Tables[0].Select("name='" + cbxType.SelectedItem.ToString()+"'"))[0]; //声明一个参数的对象数组 object[] args =null; //若有参数，则将其分割成字符串数组，用于实例化时所用的参数 if (dr["para"].ToString() != "") args = dr["para"].ToString().Split(','); //通过反射实例化出相应的算法对象 cc.setBehavior(dr["class"].ToString(), args); 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(); }
而我们的配置类就应该是实现反射的类如下：
View Codeclass CashContext { private CashSuper cs; public void setBehavior(string className, object[] args) { this.cs = (CashSuper)Assembly.Load("商场管理软件").CreateInstance("商场管理软件." + className, false, BindingFlags.Default, null, args, null, null); } public double GetResult(double money) { return cs.acceptCash(money); } }
到此为止我们使用简单工厂策略模式+反射实现了一种数据驱动的方式实现了代码0修改。
数据驱动是我们常用的一种设计方案，这是一种伟大的进步，从数据驱动直到今天的脚本游戏引擎比如说unity3d............扯远了....下一篇来吧....................................
如果需要可以下载源码:D
http://www.cnblogs.com/Wonder1989/archive/2013/03/27/2985275.html
本博客不在跟新 请移步http://www.cnblogs.com/Wonder1989
