虫子以前在一家电商公司 会员的模块在这里分类很明确
不同的会员所具有的权限和行为不同，大多程序员会使用标准的oo技术，设计一个会员超类SuperUser，并让各种商家会员继承此超类
到这里无可厚非，但是在下面个过程中你可以就慢慢体会策略模式与你在代码里不停写逻辑判断所带来的区别有多大
所有的会员都具有下列行为
购物，评价，发布商品
View Code public abstract class SuperUser { public SuperUser() { } public void shopping() { Console.WriteLine( " shopping "); } public void Comment() { Console.WriteLine( " Comment "); } public abstract void Promote(); } public class UserA : SuperUser { public override void Promote() { Console.WriteLine( " 推广A类商品 "); } } public class UserB : SuperUser { public override void Promote() { Console.WriteLine( " 推广B类商品 "); } }
因为不同商家会员只能推广指定类型的商品所以这里Promote方法抽象出来
好吧 现在我们来了一个新需求 对于B类的用户 进行购物折价
加在什么地方 超类？ 不 并不是所有的会员都拥有折价 逻辑判断？ 是个方法 不过对于不断需求的变更 在庞大臃肿的领域模型中 时间长了 也hold不住 更何况还不停有不同的商家会员分类加进来 并且在大型web架构中作为基站的程序不适合频繁更新
既然这样 利用接口如何 对改变关闭 对扩展开放
View Code public interface discountBehavior { void discount(); } public class diswithB : discountBehavior { public void discount() { Console.WriteLine( " 能打折扣呃 "); } } public class Nodis : discountBehavior { public void discount() { Console.WriteLine( " 不能打折扣 "); } } public abstract class SuperUser { public SuperUser() { } public void shopping() { Console.WriteLine( " shopping "); } public void Comment() { Console.WriteLine( " Comment "); } public abstract void Promote(); public discountBehavior dcbehavior; public void discount() { dcbehavior.discount(); } } public class UserA : SuperUser, discountBehavior { public UserA() { dcbehavior = new Nodis(); } public override void Promote() { Console.WriteLine( " 推广A类商品 "); } } public class UserB : SuperUser, discountBehavior { public UserB() { dcbehavior = new diswithB(); } public override void Promote() { Console.WriteLine( " 推广B类商品 "); } }
下面我们再来试试动态设定行为
在超类中加个方法
View Code public void setdiscountBehavior(discountBehavior dh) { dcbehavior = dh; }
这样就可以“随时”调用这个方法 改变会员的行为
总结：
策略模式：针对接口编程，而不是针对实现编程。多用组合少用继承。策略模式定义了算法簇，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。