设计模式——组件协作模式之策略模式

简介: 现代软件专业分工之后的第一个结果是 “框架与应用程序的划分”,“组件协作” 模式通过晚期绑定,来实现框架与应用程序之间的松耦合,是二者之间协作时常用的模式。

前言



一、“组件协作” 模式


现代软件专业分工之后的第一个结果是 “框架与应用程序的划分”,“组件协作” 模式通过晚期绑定,来实现框架与应用程序之间的松耦合,是二者之间协作时常用的模式。

典型模式

Template Method

Observer / Event

Strategy


二、Strategy 策略模式



1、动机


在软件构建过程中,某些对象使用的算法可能多种多样,经常改变,如果将这些算法都编码到对象中,将会使对象变得异常复杂;而且有时候支持不使用的算法也是一个性能负担。

如何在运行时根据需要透明地更改对象的算法?将算法与对象本身解耦,从而避免上述问题?


2、模式定义


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


3、代码示例


下面假设这样一个场景,比如说我们在电子商务系统中常常需要做订单的计算,订单计算中常常有金额、交易等等计算,此外还有一个很重要的是税的计算,假如我们支持跨国计算的话,那么这里就需要考虑不同国家税的算法的不同,现在在已有中国、美国和德国计算税的基础上增加一个支持德国的税计算算法。

下面展示两种方法的伪代码:


strategy1.cpp

//strategy1.cpp
enum TaxBase {
    CN_Tax,
    US_Tax,
    DE_Tax,
    FR_Tax       //更改
};
class SalesOrder{
    TaxBase tax;
public:
    double CalculateTax(){
        //...
        if (tax == CN_Tax){
            //CN***********
        }
        else if (tax == US_Tax){
            //US***********
        }
        else if (tax == DE_Tax){
            //DE***********
        }
        else if (tax == FR_Tax){  //更改
            //...
        }
        //....
     }
};
//说明:这种方式更改的时候违反了开放封闭原则

strategy2.cpp

//strategy2.cpp
class TaxStrategy{
public:
    virtual double Calculate(const Context& context)=0;
    virtual ~TaxStrategy(){}
};
//规范的写法是每个类放在不同的文件中
class CNTax : public TaxStrategy{
public:
    virtual double Calculate(const Context& context){
        //***********
    }
};
class USTax : public TaxStrategy{
public:
    virtual double Calculate(const Context& context){
        //***********
    }
};
class DETax : public TaxStrategy{
public:
    virtual double Calculate(const Context& context){
        //***********
    }
};
//扩展:正常应该是在一个新的文件中写,此处只是为了方便演示
//*********************************
class FRTax : public TaxStrategy{
public:
    virtual double Calculate(const Context& context){
        //.........
    }
};
class SalesOrder{
private:
    TaxStrategy* strategy; //抽象类,必须放一个指针,而且具有多态性
public:
    SalesOrder(StrategyFactory* strategyFactory){
        this->strategy = strategyFactory->NewStrategy(); // 工厂模式创建对象
    }
    ~SalesOrder(){
        delete this->strategy;
    }
    public double CalculateTax(){
        //...
        Context context();
        double val = 
            strategy->Calculate(context); //多态调用
        //...
    }
};
//说明:这种方式扩展的时候遵循了开放封闭原则
  • 复用指的是编译后二进制意义的复用,而不是简单的代码片段的复用。
  • SalesOrder 和 TaxStrategy是稳定的,各种XXTax 是变化的。

4、结构


【注】:

Context 和 Strategy 是稳定的

ConcreteStrategyX 是变化的


要点总结


Strategy 及其子类为组件提供了一系列可重用的算法,从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。


Strategy 模式提供了用条件判断语句以外的另一种选择,消除条件判断语句,就是在解耦合。含有许多条件判断语句的代码通常都需要 Strategy 模式。


【注】:绝对稳定不变的情况可以用if-else,如一周七天,而其他的可能变化条件判断的情况就要用Strategy模式。代码示例中的第一种写法的很多条件判断代码可能根本不会执行,但是却被迫装载到了CPU高级缓存中,占用了缓存位置,其他代码可能被挤出高级缓存,不得不装载到硬盘;而第二种写法则不会有这个问题,减轻了性能负担,但这不是Strategy模式的最大优势,Strategy模式的最大优势是用扩展应对变化。看到条件判断的情况,都要考虑能不能使用Strategy模式。】


如果 Strategy 对象没有实例变量,那么各个上下文可以共享同一个 Strategy 对象,从而节省对象开销。【注:一般可以使用单例模式】


目录
相关文章
|
5天前
|
设计模式 uml
设计模式-------------工厂模式之工厂方法模式(创建型)
工厂方法模式是一种创建型设计模式,它通过定义一个用于创建对象的接口,让子类决定实例化哪一个类,从而实现类的实例化推迟到子类中进行,提高了系统的灵活性和可扩展性。
设计模式-------------工厂模式之工厂方法模式(创建型)
|
5天前
|
设计模式 uml C语言
设计模式----------工厂模式之简单工厂模式(创建型)
这篇文章详细介绍了简单工厂模式,包括其定义、应用场景、UML类图、通用代码实现、运行结果、实际应用例子,以及如何通过反射机制实现对象创建,从而提高代码的扩展性和维护性。
设计模式----------工厂模式之简单工厂模式(创建型)
|
6天前
|
设计模式 uml
设计模式-------------工厂模式之工厂方法模式(创建型)
工厂方法模式是一种创建型设计模式,它通过定义一个用于创建对象的接口,让子类决定实例化哪一个类,从而实现类的实例化推迟到子类中进行,提高了系统的灵活性和可扩展性。
|
6天前
|
设计模式 uml C语言
设计模式----------工厂模式之简单工厂模式(创建型)
这篇文章详细介绍了简单工厂模式,包括其定义、应用场景、UML类图、通用代码实现、运行结果、实际应用例子,以及如何通过反射机制实现对象创建,从而提高代码的扩展性和维护性。
设计模式----------工厂模式之简单工厂模式(创建型)
|
5天前
|
设计模式 人工智能 达摩院
设计模式的基础问题之模板模式在软件开发中的优势是什么
设计模式的基础问题之模板模式在软件开发中的优势是什么
|
5天前
|
设计模式 项目管理
设计模式的基础问题之生成器模式在项目管理应用的问题如何解决
设计模式的基础问题之生成器模式在项目管理应用的问题如何解决
|
6天前
|
设计模式 Java API
设计模式-------------静态/动态代理模式(结构型设计模式)
本文详细介绍了代理模式,包括其定义、应用场景、UML类图、代码实现和实际例子,阐述了静态代理和动态代理的区别以及它们的优缺点,展示了如何通过代理模式来控制对目标对象的访问并增强其功能。
|
12天前
|
设计模式 测试技术 Go
[设计模式]创建型模式-简单工厂模式
[设计模式]创建型模式-简单工厂模式
|
1月前
|
设计模式 算法 Java
跟着GPT学设计模式之模板模式
模板模式是一种行为型设计模式,它定义了一个操作中的算法骨架,将一些步骤的具体实现延迟到子类中。该模式使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
41 6
|
1月前
|
设计模式 Go
Go语言设计模式:使用Option模式简化类的初始化
在Go语言中,面对构造函数参数过多导致的复杂性问题,可以采用Option模式。Option模式通过函数选项提供灵活的配置,增强了构造函数的可读性和可扩展性。以`Foo`为例,通过定义如`WithName`、`WithAge`、`WithDB`等设置器函数,调用者可以选择性地传递所需参数,避免了记忆参数顺序和类型。这种模式提升了代码的维护性和灵活性,特别是在处理多配置场景时。
54 8