标签:设计模式 策略模式
<?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
标签:设计模式 策略模式
原文地址:http://noican.blog.51cto.com/4081966/1614783