<?php
/**
* 3.1 策略模式
* 定义：
* 它定义了算法家族，分别封装起来，让它们之间可以互相
* 替换，此模式让算法的变化，不会影响到使用算法的客户。
* 角色：
* 1. 抽象算法类
* 2. 具体算法类
* 3. 上下文类
* 优点：
* 1. 提供了挂历相关算法族的办法。策略类的等级结构定义
* 了一个算法或行为族。恰当的使用继承可以把公共的代
* 码转移到父类里面，从而避免重复的代码。
* 2. 提供了替换继承关系的办法。继承可以处理多种算法和
* 行为。如果不是使用策略模式，那么使用算法或行为的
* 环境就看可能会有一些子类，每一个子类提供一个不同
* 的算法或行为。但是这样一来算法或行为的使用者就和
* 算法或行为本身混在一起。决定使用哪一种算法或采取
* 哪一种行为的逻辑就和算法或行为的逻辑混在一起，从
* 而不可能在独立演化。继承使得动态改变算法或行为变
* 的不可能。
* 3. 使用策略模式可以避免使用多重条件转移语句。多重转
* 移语句不易维护，它把采取哪一种算法或采取哪一种行
* 为的逻辑与算法或行为的逻辑混在一起，统统列在一个
* 多重转移条件里面，比使用继承的部分还要原始和落后
* 缺点：
* 1. 客户端必须知道所有的策略类，并自行决定使用哪一个
* 策略类。这就意味着客户端必须理解这些算法的区别，
* 以便适时选择恰当的算法类。换言之，策略模式只适用
* 于客户端知道所有算法或行为的情况。
* 2. 策略模式造成很多的策略类，每个具体策略类都会产生
* 一个新类。有时候可以通过把依赖于环境的状态保存到
* 客户端里面，而将处理类设计成可共享的，这样策略类
* 可以被不同客户端使用。换言之，可以使用享元模式来
* 减少对象的数量。
* 使用场景：
* 1. 多个类只区别在表现行为不同，可以使用此模式，在运
* 行时选择具体要执行的行为。
* 2. 需要在不同情况下是使用不同的策略，或者策略还可能
* 在未来用其他方式来实现。
* 3. 对客户隐藏具体策略的实现细节，彼此完全对立。
*/
header('content-type:text/html;charset=utf8');
//抽象算法类
abstract class Strategy{
abstract public function AlgorithmInterface();
}
//具体算法类A
class ConcreteStrategyA extends Strategy{
public function AlgorithmInterface(){
echo '算法A实现';
}
}
//具体算法类B
class ConcreteStrategyB extends Strategy{
public function AlgorithmInterface(){
echo '算法B实现';
}
}
//具体算法类C
class ConcreteStrategyC extends Strategy{
public function AlgorithmInterface(){
echo '算法C实现';
}
}
//上下文
class Context{
private $strategy;
public function __construct(Strategy $strategy){
$this->strategy=$strategy;
}
//得到具体算法的结果
public function getResult(){
$this->strategy->AlgorithmInterface();
}
}
//上下文类――改进版
class ContextImprove{
public static function getResult($Algorithm){
$str='ConcreteStrategy'.$Algorithm;
$alg=new ReflectionClass($str);
return $alg->newInstance()->AlgorithmInterface();
}
}
//客户端
$context=new Context(new ConcreteStrategyA());
$context->getResult();
echo '<br/>';
//客户端――改进版
echo ContextImprove::getResult('A');
本文出自 “一切皆有可能” 博客，请务必保留此出处http://noican.blog.51cto.com/4081966/1614783