设计模式-15章(策略模式)

设计模式
设计模式
发布日期:   2024-01-24
更新日期:   2024-01-24
文章字数:   2.5k
阅读时长:   9 分
阅读次数:  

第十五章 策略模式

策略模式（Strategy Pattern）是面向对象编程中的一种行为设计模式，它允许你定义一系列算法，将每个算法封装起来，并使它们可以相互替换。策略模式使算法的选择独立于使用算法的客户端，这使得客户端可以在不改变其代码的情况下轻松地切换不同的算法。策略模式有助于减少条件语句的使用，提高代码的可维护性和可扩展性。

策略模式通常涉及以下角色：

  1. Context（上下文）：上下文是客户端与策略模式之间的接口。它包含一个指向策略对象的引用，允许客户端在运行时切换不同的策略。上下文将具体的算法委托给策略对象执行。

  2. Strategy（策略）：策略是一个接口或抽象类，它定义了一组算法的通用接口。具体的策略类实现了这个接口，并提供了不同的算法实现。

  3. Concrete Strategy（具体策略）：具体策略是策略接口的具体实现，每个具体策略类都代表一种不同的算法。客户端可以选择不同的具体策略来处理特定的问题。

下面是一个使用策略模式的简单示例，假设我们要实现一个图像编辑器，可以选择不同的滤镜来处理图像：

// 策略接口
interface FilterStrategy {
    void applyFilter(String fileName);
}

// 具体策略1：黑白滤镜
class BlackAndWhiteFilter implements FilterStrategy {
    @Override
    public void applyFilter(String fileName) {
        System.out.println("Applying Black and White Filter to " + fileName);
        // 实际的滤镜处理逻辑
    }
}

// 具体策略2：模糊滤镜
class BlurFilter implements FilterStrategy {
    @Override
    public void applyFilter(String fileName) {
        System.out.println("Applying Blur Filter to " + fileName);
        // 实际的滤镜处理逻辑
    }
}

// 上下文
class ImageEditor {
    private FilterStrategy filter;

    public void setFilter(FilterStrategy filter) {
        this.filter = filter;
    }

    public void processImage(String fileName) {
        this.filter.applyFilter(fileName);
    }
}

public class Main {
    public static void main(String[] args) {
        ImageEditor editor = new ImageEditor();

        // 切换不同的滤镜
        editor.setFilter(new BlackAndWhiteFilter());
        editor.processImage("image1.jpg");

        editor.setFilter(new BlurFilter());
        editor.processImage("image2.jpg");
    }
}

在上面的示例中，我们定义了两种具体的滤镜策略（BlackAndWhiteFilter和BlurFilter），并使用上下文类ImageEditor来切换不同的滤镜策略。这允许我们在不改变ImageEditor类的情况下轻松地添加新的滤镜。

在实际的项目开发中，这个模式也比较常用。最常见的应用场景是，利用它来避免冗长的 if-else 或 switch 分支判断。不过，它的作用还不止如此。它也可以像模板模式那样，提供框架的扩展点等等。

1. 策略模式的原理与实现

策略模式，英文全称是 Strategy Design Pattern。在 GoF 的《设计模式》一书中，它是这样定义的：

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

翻译成中文就是：定义一族算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式可以使算法的变化独立于使用它们的客户端（这里的客户端代指使用算法的代码）。

我们知道，工厂模式是解耦对象的创建和使用，观察者模式是解耦观察者和被观察者。策略模式跟两者类似，也能起到解耦的作用，不过，它解耦的是策略的定义、创建、使用这三部分。接下来，我就详细讲讲一个完整的策略模式应该包含的这三个部分。

1.1 策略的定义

策略类的定义比较简单，包含一个策略接口和一组实现这个接口的策略类。因为所有的策略类都实现相同的接口，所以，客户端代码基于接口而非实现编程，可以灵活地替换不同的策略。示例代码如下所示：

public interface Strategy {
    void algorithmInterface();
}

public class ConcreteStrategyA implements Strategy {
    @Override
    public void algorithmInterface() {
        //具体的算法...
    }
}

public class ConcreteStrategyB implements Strategy {
    @Override
    public void algorithmInterface() {
        //具体的算法...
    }
}

1.2 策略的创建

public class StrategyFactory {
    private static final Map<String, Strategy> strategies = new HashMap<>();
    static {
        strategies.put("A", new ConcreteStrategyA());
        strategies.put("B", new ConcreteStrategyB());
    }
    
    public static Strategy getStrategy(String type) {
        if (type == null || type.isEmpty()) {
            throw new IllegalArgumentException("type should not be empty.");
        }
        return strategies.get(type);
    }
}

一般来讲，如果策略类是无状态的，即不包含成员变量，只是纯粹的算法实现，这样的策略对象是可以被共享使用的，不需要在每次调用 getStrategy() 的时候，都创建一个新的策略对象。针对这种情况，我们可以使用上面这种工厂类的实现方式，事先创建好每个策略对象，缓存到工厂类中，用的时候直接返回。

相反，如果策略类是有状态的，根据业务场景的需要，我们希望每次从工厂方法中，获得的都是新创建的策略对象，而不是缓存好可共享的策略对象，那我们就需要按照如下方式来实现策略工厂类。

public class StrategyFactory {
    public static Strategy getStrategy(String type) {
        if (type == null || type.isEmpty()) {
            throw new IllegalArgumentException("type should not be empty.");
        }
        
        if (type.equals("A")) {
            return new ConcreteStrategyA();
        } else if (type.equals("B")) {
            return new ConcreteStrategyB();
        }
        return null;
    }
}

1.3 策略的使用

刚刚讲了策略的定义和创建，现在，我们再来看一下，策略的使用。

我们知道，策略模式包含一组可选策略，客户端代码一般如何确定使用哪个策略呢？最常见的是运行时动态确定使用哪种策略，这也是策略模式最典型的应用场景。

这里的“运行时动态”指的是，我们事先并不知道会使用哪个策略，而是在程序运行期间，根据配置、用户输入、计算结果等这些不确定因素，动态决定使用哪种策略。接下来，我们通过一个例子来解释一下。

// 策略接口：EvictionStrategy
// 策略类：LruEvictionStrategy、FifoEvictionStrategy、LfuEvictionStrategy...
// 策略工厂：EvictionStrategyFactory
public class UserCache {
    private Map<String, User> cacheData = new HashMap<>();
    private EvictionStrategy eviction;
    
    public UserCache(EvictionStrategy eviction) {
        this.eviction = eviction;
    }
    //...
}

// 运行时动态确定，根据配置文件的配置决定使用哪种策略
public class Application {
    public static void main(String[] args) throws Exception {
        EvictionStrategy evictionStrategy = null;
        //读取配置文件
        Properties props = new Properties();
        props.load(new FileInputStream("./config.properties"));
        String type = props.getProperty("eviction_type");
        //根据配置文件来决定使用哪种策略
        evictionStrategy = EvictionStrategyFactory.getEvictionStrategy(type);
        UserCache userCache = new UserCache(evictionStrategy);
        //...
    }
}

// 非运行时动态确定，在代码中指定使用哪种策略
public class Application {
    public static void main(String[] args) {
        //...
        EvictionStrategy evictionStrategy = new LruEvictionStrategy();
        UserCache userCache = new UserCache(evictionStrategy);
        //...
    }
}

从上面的代码中，我们也可以看出，“非运行时动态确定”，也就是第二个 Application中的使用方式，并不能发挥策略模式的优势。在这种应用场景下，策略模式实际上退化成了“面向对象的多态特性”或“基于接口而非实现编程原则“

2. 如何利用策略模式避免分支判断？

实际上，能够移除分支判断逻辑的模式不仅仅有策略模式，后面我们要讲的状态模式也可以。对于使用哪种模式，具体还要看应用场景来定。 策略模式适用于根据不同类型待动态，决定使用哪种策略这样一种应用场景。

我们先通过一个例子来看下，if-else 或 switch-case 分支判断逻辑是如何产生的。具体的代码如下所示。在这个例子中，我们没有使用策略模式，而是将策略的定义、创建、使用直接耦合在一起。

public class OrderService {
    public double discount(Order order) {
        double discount = 0.0;
        OrderType type = order.getType();
        
        if (type.equals(OrderType.NORMAL)) { // 普通订单
            //...省略折扣计算算法代码
        } else if (type.equals(OrderType.GROUPON)) { // 团购订单
            //...省略折扣计算算法代码
        } else if (type.equals(OrderType.PROMOTION)) { // 促销订单
            //...省略折扣计算算法代码
        }
        return discount;
    }
}

如何来移除掉分支判断逻辑呢？那策略模式就派上用场了。我们使用策略模式对上面的代码重构，将不同类型订单的打折策略设计成策略类，并由工厂类来负责创建策略对象。具体的代码如下所示：

策略的定义：

public interface DiscountStrategy {
    double calDiscount(Order order);
}

省略NormalDiscountStrategy、GrouponDiscountStrategy、PromotionDiscountStrateg

策略的创建：

public class DiscountStrategyFactory {
    private static final Map<OrderType, DiscountStrategy> strategies = new HashMap();
    static {
        strategies.put(OrderType.NORMAL, new NormalDiscountStrategy());
        strategies.put(OrderType.GROUPON, new GrouponDiscountStrategy());
        strategies.put(OrderType.PROMOTION, new PromotionDiscountStrategy());
    }
    
    public static DiscountStrategy getDiscountStrategy(OrderType type) {
        return strategies.get(type);
    }
}

策略的使用：

public class OrderService {
    public double discount(Order order) {
        OrderType type = order.getType();
        DiscountStrategy discountStrategy = DiscountStrategyFactory.getDiscountStrategy(type);
        return discountStrategy.calDiscount(order);
    }
}

重构之后的代码就没有了 if-else 分支判断语句了。实际上，这得益于策略工厂类。在工厂类中，我们用 Map 来缓存策略，根据 type 直接从 Map 中获取对应的策略，从而避免 if-else 分支判断逻辑。等后面讲到使用状态模式来避免分支判断逻辑的时候，你会发现，它们使用的是同样的套路。本质上都是借助“查表法”，根据 type 查表（代码中的strategies 就是表）替代根据 type 分支判断。

但是，如果业务场景需要每次都创建不同的策略对象，我们就要用另外一种工厂类的实现方式了。具体的代码如下所示：

上面的实现是每次创建的是相同的策略对象，因为是使用Map来缓存起来的。

public class DiscountStrategyFactory {
    public static DiscountStrategy getDiscountStrategy(OrderType type) {
        if (type == null) {
            throw new IllegalArgumentException("Type should not be null.");
        }
        if (type.equals(OrderType.NORMAL)) {
            return new NormalDiscountStrategy();
        } else if (type.equals(OrderType.GROUPON)) {
            return new GrouponDiscountStrategy();
        } else if (type.equals(OrderType.PROMOTION)) {
            return new PromotionDiscountStrategy();
        }
        return null;
    }
}

这种实现方式相当于把原来的 if-else 分支逻辑，从 OrderService 类中转移到了工厂类中，实际上并没有真正将它移除，但是已经很优雅了。

文章作者: 念心卓
文章链接: http://blog.cqwulyj.cn/posts/ab07f3f9.html
版权声明: 本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源 念心卓 !
设计模式
  目录