结合项目实例 回顾传统设计模式（一）策略模式

虫子以前在一家电商公司 会员的模块在这里分类很明确

不同的会员所具有的权限和行为不同，大多程序员会使用标准的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

            Console.WriteLine("推广B类商品");

因为不同商家会员只能推广指定类型的商品所以这里Promote方法抽象出来

好吧 现在我们来了一个新需求 对于B类的用户 进行购物折价

加在什么地方 超类？ 不 并不是所有的会员都拥有折价 逻辑判断？ 是个方法 不过对于不断需求的变更 在庞大臃肿的领域模型中 时间长了 也hold不住 更何况还不停有不同的商家会员分类加进来 并且在大型web架构中作为基站的程序不适合频繁更新

既然这样 利用接口如何 对改变关闭 对扩展开放

public interface discountBehavior

         void discount();

    public class diswithB : discountBehavior

        public void discount()

            Console.WriteLine("能打折扣呃");

    public class Nodis : discountBehavior

            Console.WriteLine("不能打折扣");

    public abstract class SuperUser

        public discountBehavior dcbehavior;

            dcbehavior.discount();

    public class UserA : SuperUser, discountBehavior

        public UserA()

            dcbehavior = new Nodis();

    public class UserB : SuperUser, discountBehavior

        public UserB()

            dcbehavior = new diswithB();

下面我们再来试试动态设定行为

在超类中加个方法

 public void setdiscountBehavior(discountBehavior dh)

            dcbehavior = dh;

这样就可以“随时”调用这个方法 改变会员的行为

总结：

策略模式：针对接口编程，而不是针对实现编程。多用组合少用继承。策略模式定义了算法簇，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。

本文转自 熬夜的虫子  51CTO博客，原文链接:http://blog.51cto.com/dubing/712402