【笔记】大话设计模式-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)
开放-封闭原则是面向对象设计的核心所在。遵循该原则,可使程序可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现的频繁变化的那些部分做出抽象。
对于程序中的每个部分都可以进行抽象也不是一个好办法。拒绝不成熟的抽象和抽象本身一样重要。
以上。