策略模式

对象行为型模式,主要是定义一系列的算法,把这些算法一个个封装成单独的类

先看看涉及的设计原则

1，找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。

这个概念很简单，几乎是每个设计模式背后的精神所在。所有的模式都提供了一套方法让“系统中的某部分改变不会影响其他部分”。

2，针对接口（超类型）编程，而不是针对实现编程。

"针对实现编程"

Dog d = new Dog();

d.bark();//声明d为Dog类型（Animal的具体实现），急造成我们必须针对具体实现编码。

但是，“针对接口/超类型编程”做法会如下：

Animal animal = new Dog();

animal.makeSound();//我们知道该对象是狗，但是现在利用animal进行多态调用。

更棒的例子是，子类的实例化不再需要在代码中硬编码，而是“在运行时才制定具体实现的对象”。

a = getAnimal();

a.makeSound();//我们不关心子类的类型是什么，我们只关心它知道如何进行makeSound()的动作就够了。

3，多用组合，少用继承

“有一个”可能比“是一个”更好。

Duck对flybehavior和quackBehavior都是有一个。

策略模式的定义了算法族，分别封装起来，让它们之间可以互相转换，此模式算法的变化独立于使用算法的客户。

Context(应用场景):

l         需要使用ConcreteStrategy提供的算法。

l         内部维护一个Strategy的实例。

l         负责动态设置运行时Strategy具体的实现算法。

l         负责跟Strategy之间的交互和数据传递。

Strategy(抽象策略类)：

l         定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，Context使用这个接口调用不同的算法，一般使用接口或抽象类实现。

ConcreteStrategy(具体策略类)：

l         实现了Strategy定义的接口，提供具体的算法实现。

应用时序图：

对于Strategy模式来说，主要有这些应用场景：

1、  多个类只区别在表现行为不同，可以使用Strategy模式，在运行时动态选择具体要执行的行为。(例如FlyBehavior和QuackBehavior)

2、  需要在不同情况下使用不同的策略(算法)，或者策略还可能在未来用其它方式来实现。(例如FlyBehavior和QuackBehavior的具体实现可任意变化或扩充)

3、  对客户(Duck)隐藏具体策略(算法)的实现细节，彼此完全独立。

 

对于Strategy模式来说，主要有如下优点：

1、  提供了一种替代继承的方法，而且既保持了继承的优点(代码重用)还比继承更灵活(算法独立，可以任意扩展)。

2、  避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。

3、  遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。

对于Strategy模式来说，主要有如下缺点：

1、  因为每个具体策略类都会产生一个新类，所以会增加系统需要维护的类的数量。

更具体一点，Strategy适合下列场合:

1.以不同的格式保存文件;

2.以不同的算法压缩文件;

3.以不同的算法截获图象;

4.以不同的格式输出同样数据的图形,比如曲线 或框图bar等

模式时oo基础的隐形经验，抽象，封装，多态，继承。

要点：

1，知道oo继承，并不足以让你设计出良好的oo系统。

2，良好的oo设计必须具备可复用性，可扩充，可维护三个特性。

3，模式可以让我们建造出具有良好oo设计质量的系统。

4，模式被认为是历经验证的oo设计经验。

5，模式不是代码，而是针对设计问题的通用解决方案。你可把它们应用到特定的应用中。

6，模式不是被发明，而是被发现。

7，大多数的模式和原则，都着眼于软件变化的主题。

8，大多数的模式都允许系统局部改变独立于其他部分。

9，我们常把系统中的会变化的部分抽出来封装。

10，模式让开发人员之间有共享的语言，能够最大化沟通的价值。

参考http://www.cnblogs.com/justinw/archive/2007/02/06/641414.html

http://www.jdon.com/designpatterns/designpattern_Strategy.htm