一、开篇
上篇文章【大话设计模式】——简单工厂模式告诉了我们一个网吧收费工厂对象怎样创建收费形式(白天收费、夜间收费)的实例。简单工厂代码中有非常多 case分支语句 ,假设我们还想填加收费的形式(比方会员收费啊,通宵收费啊),就须要修改工厂代码,每次维护和扩展都要花费非常多时间,另外修改非常easy造成纰漏(比方之前的白天收费形式,非常可能由于修改从多收钱或者少收钱),所以简单工厂模式非常不安全。所以我们要把常常变化的代码抽象出来,做到业务逻辑和界面逻辑分开,仅仅有这样才干更加easy做到维护和扩展。
发现问题,解决这个问题,人类就这样一点一滴的进步着。
发现了简单工厂的不好,策略模式就诞生啦,人类真的是非常睿智!(呱唧呱唧)
以下大家熟悉一下策略模式的定义:
策略模式(Strategy):它定义了算法家族,分别封装起来。让她们之间能够互相替换,此模式让算法的变化,不会影响到使用算法的客户。
二、UML图
Context(环境类):须要使用ConcreteStrategy的详细算法,维护一个对Strategy对象的引用,负责跟Strategy之间的交互和数据传递。
Strategy(抽象策略类):定义全部支持的算法的公共接口。Context使用这个接口来调用ConcreteStrategy算法。
ConcreteStrategy(详细策略类):封装了详细的算法和行为,继承与Strategy.
图中含有两种关系,聚合和继承。
三、实例解析
比方我们填饱肚子的方式,有几个策略能够考虑:吃水果、吃蔬菜、吃馒头。
首先定义一个抽象类吃,然后让吃的形式:吃水果,吃蔬菜,吃馒头继承这个抽象吃类,再声明一个Context类,用来配置吃的方法。维护一个对Strategy对象的引用。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace ConsoleApplication7
{
class Program
{
static void Main(string[] args)//client代码
{
Context context;
context = new Context(new EatingFruit());//实例化不同的策略,调用的时候获得的结果就不同。
context.ContextInterface();
context = new Context(new EatingVegetables());
context.ContextInterface();
context = new Context(new EatingSteamBread());
context.ContextInterface();
}
}
abstract class EatStrategy//抽象吃法类
{
public abstract void Eat();
}
class EatingFruit:EatStrategy //详细吃法吃苹果
{
public override void Eat()
{
Console .WriteLine ("饿了吃苹果");
}
}
class EatingVegetables : EatStrategy//详细吃法吃蔬菜
{
public override void Eat()
{
Console .WriteLine ("吃蔬菜也不饿");
}
}
class EatingSteamBread : EatStrategy//详细吃法吃馒头
{
public override void Eat()
{
Console .WriteLine ("吃馒头也不错");
}
}
class Context//写策略环境类
{
EatStrategy eatstrategy;
public Context(EatStrategy eatstrategy)//初始化时,传入详细的策略对象
{
this.eatstrategy = eatstrategy;
}
//上下文接口
public void ContextInterface()//依据详细的策略对象。调用其算法的方法
{
eatstrategy.Eat();
}
}
}
四、总结
策略模式的长处:
1)全部的算法完毕同样的工作。仅仅是实现不同,它以同样的方式调用全部的算法,降低了各种算法类与使用算法类之间的耦合。
个人理解:无论是吃水果还是吃蔬菜。异或是吃馒头。都是为了填饱肚子,尽管形式不同,假设有的人挑食吃饭一定要吃菜加馒头才肯吃。那假设没有卖馒头的。你就要减肥啦~
2)策略模式Strategy类层次为Context定义了一系列的可供重用的算法和行为。继承有助于析取出这些算法中的公共功能。
个人理解:把东西分类放置。使用的时候就更加easy找到。
3)简化了单元測试。由于每一个算法都有自己的类,能够通过自己的接口单独測试。
个人理解:有单独的类,就更easy满足单一职责原则,这样測试一个功能,数据假设不正确,直接就能划分出范围。
比方值日分为扫地和擦桌子,安排小明拖地,小红擦桌子。假设值完日了,地面还脏。那肯定就是小明干的不好呗(当然排除搞破坏的可能)。可是假设你让两个人干活,又没有分配任务,那好了,挨罚就两个人一起做个伴吧!
4)算法封装在单独的类中。能够消除条件语句,为client减轻了压力。
个人理解:领导者假设负责一个非常庞大的project的话。那些琐事会让他局限于细节,而失去了把控能力。
缺点:
1)client必须知道全部的策略类,并自行决定使用哪个策略类。
2)Strategy和Context之间存在通信开销
3)假设详细策略过多,会产生非常多的策略类,添加了维护的难度。
代码即人生啊~