1. 首页
    2. 设计模式

    【设计模式】第3篇-策略模式

    定义

    定义一系列算法,把它们一个个封装起来,并且使它们可互相替换(变化)。该模式使得算法可独立于使用它的客户程序(稳定)而变化(扩展,子类化)

    动机
    • 在软件构建过程中,某些对象使用的算法可能多种多样,经常改
      变,如果将这些算法都编码到对象中,将会使对象变得异常复杂;
      而且有时候支持不使用的算法也是一个性能负担。
    • 如何在运行时根据需要透明地更改对象的算法?将算法与对象本
      身解耦,从而避免上述问题?
    结构

    要点
    • Strategy及其子类为组件提供了一系列可重用的算法,从而可以使
      得类型在运行时方便地根据需要在各个算法之间进行切换。
    • Strategy模式提供了用条件判断语句以外的另一种选择,消除条件
      判断语句,就是在解耦合。含有许多条件判断语句的代码通常都需
      要Strategy模式。
    • 如果Strategy对象没有实例变量,那么各个上下文可以共享同一个
      Strategy对象,从而节省对象开销。
    代码

    此段代码的问题在于,当新增国家时,既要修改枚举类,又要修改源代码,违背了开闭原则

    enum TaxBase {
    	ZH_TAX,
    	EN_TAX,
    	US_TAX
    };
    class SalesOrder {
    public:
    	double calculateTax() {
    		//...
    		if (tax == ZH_TAX) {
    			//...
    		}
    		else if (tax == EN_TAX) {
    			//...
    		}
    		else if (tax == US_TAX)	{
    			//...
    		}
    	}
    private:
    	TaxBase tax;
    };
    

    将每个国家的税法算法封装为类,统一接口,这样在新增国家时,只需要增量添加即可

    class TaxStrategy {
    public:
    	virtual double calculate() = 0;
    	virtual ~TaxStrategy() {};
    };
    class ZHTax :public TaxStrategy {
    public:
    	double calculate() {
    		//...
    	}
    };
    class ENTax :public TaxStrategy {
    public:
    	double calculate() {
    		//...
    	}
    };
    class USTax :public TaxStrategy {
    public:
    	double calculate() {
    		//...
    	}
    };
    class SalesOrder {
    public:
    	SalesOrder(TaxStrategy* t) :strategy(t) {}
    public:
    	double taxCalculate() {
    		return strategy->calculate();
    	}
    private:
    	TaxStrategy * strategy;
    };
    评分 0, 满分 5 星
    0
    0
    看完收藏一下,下次也能找得到
    • 版权声明:本文基于《知识共享署名-相同方式共享 3.0 中国大陆许可协议》发布,转载请遵循本协议
    • 文章链接:https://icebmji.com/blog/?p=532 [复制] (转载时请注明本文出处及文章链接)
    上一篇:
    :下一篇

    评论已关闭