【笔记】大话设计模式-234

【笔记】大话设计模式-234

2 策略模式(Strategy)

简介

一般商场里面,都会有许多促销模式,正常模式,满多少返多少,还有直接打几折的。需要根据不同模式,收取不同金额。

可以使用简单工厂模式,设计一个CashFactory,然后根据打折情况,设置子类:正常模式CashNormal,打折收费子类CashRebate, 返利收费子类CashSuper,在工厂中调用不同子类即可。

简单工厂虽然也可以解决问题,但这个模式只是解决对象的创建问题,而且由于工厂本身包括了所有的收费方式,商场是可能经常更改打折额度和返利额度,比如满100积分10点的促销手段,每次维护或扩展收费方式都要改动工厂,以致代码需要重新编译部署,所以它不是最好的办法。

策略模式定义了算法家族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化,不会影响到使用算法的客户。

using System;

namespace NS_Strategy
{
    class Program
    {
        // 抽象算法类
        abstract class Strategy
        {
            //算法方法
            public abstract void AlgorithmInterface();
        }
        
        //   ConcreteStrategy 封装了具体的算法或行为,继承于Strategy   //

        // 具体算法类A
        class ConcreteStrategyA : Strategy
        {
            //算法A的具体实现方法
            public override void AlgorithmInterface()
            {
                Console.WriteLine("算法A具体实现");
            }
        }

        // 具体算法类B
        class ConcreteStrategyB : Strategy
        {
            //算法A的具体实现方法
            public override void AlgorithmInterface()
            {
                Console.WriteLine("算法B具体实现");
            }
        }

        // 具体算法类C
        class ConcreteStrategyC : Strategy
        {
            //算法A的具体实现方法
            public override void AlgorithmInterface()
            {
                Console.WriteLine("算法C具体实现");
            }
        }

        //   Context用一个ConcreteStrategy来配置,维护一个对Strategy对象的引用  //

        // 上下文
        class Context
        {
            Strategy strategy;
            public Context(Strategy strategy)
            {
                this.strategy = strategy;
            }

            // 上下文接口
            public void ContextInterface()
            {
                strategy.AlgorithmInterface();
            }
        }

         客户端代码  //
        static void Main(string[] args)
        {
            Context context;

            context = new Context(new ConcreteStrategyA());  // 实例化不同的策略
            context.ContextInterface();

            context = new Context(new ConcreteStrategyB());
            context.ContextInterface();

            context = new Context(new ConcreteStrategyC());
            context.ContextInterface();

            Console.Read();
        }
    }
}

当然可以将简单工厂与策略模式结合起来,在客户端,将Context的输入改成要判断的字符或者条件,然后直接调用不同的算法,不用在客户端依次实例化了,选择具体实现的职责可以有Context承担,这就最大化地减轻了客户端的职责。

策略模式是一种定义一系列算法的方法,从概念上看,所有这些算法完成的都是相同的工作,只是实现不同,可以以相同的方式调用所有的算法,减少了各种算法与使用算法类之间的耦合

策略模式****简化了单元测试,因为每个算法都有自己的类,可以通过自己的接口单独测试。

3 单一职责原则(SRP)

就一个类而言,应该仅有一个引起它变化的原因。

如果给一个窗体类,增加各种方法,无论什么需求变更,你都需要改变这个窗体类,维护麻烦,复用更不可能,也缺乏灵活性。

一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭到意想不到的破坏。

软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离。
如果你能想到多于一个动机去改变一个类,那么这个类就具有多于1个的职责,就应该考虑类的职责分离。

现在手机的职责越累越多,属于职责过多吗?手机携带很方便,DV,MP3等产品的体积如果能缩小100倍,像银行卡一样,或者全息投影,那时候手机功能就会显得累赘了,现在的手机就是一个过度产品。

4 开放-封闭原则

软件实体(类、模块、函数等)应该可以扩展,但是不可修改。

有两个特征:

  • 对于扩展是开放的(open for extension)
  • 对于更改是封闭的(closed for modification)
开放-封闭原则是面向对象设计的核心所在。遵循该原则,可使程序可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现的频繁变化的那些部分做出抽象。
对于程序中的每个部分都可以进行抽象也不是一个好办法。拒绝不成熟的抽象和抽象本身一样重要。

以上。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值