Strategy Design Pattern

策略模式的原理与实现

策略模式，英文全称是 Strategy Design Pattern。它是这样定义的：

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

翻译成中文就是：定义一族算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式可以使算法的变化独立于使用它们的客户端。工厂模式是解耦对象的创建和使用，观察者模式是解耦观察者和被观察者。策略模式跟两者类似，也能起到解耦的作用，不过，它解耦的是策略的定义、创建、使用这三部分。

策略的定义

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

public interface Strategy 
{
    void algorithmInterface();
}

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

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

策略的创建

因为策略模式会包含一组策略，在使用它们的时候，一般会通过类型（type）来判断创建哪个策略来使用。为了封装创建逻辑，我们需要对客户端代码屏蔽创建细节。我们可以把根据 type 创建策略的逻辑抽离出来，放到工厂类中。示例代码如下所示：

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;
    }
}

策略的使用

客户端代码运行时动态确定使用哪种策略，这也是策略模式最典型的应用场景。这里的运行时动态确定指的是，我们事先并不知道会使用哪个策略，而是在程序运行期间，根据配置、用户输入、计算结果等这些不确定因素，动态决定使用哪种策略：

// 策略接口：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);
        //...
    }
}

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

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

我们先通过一个例子来看下，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、PromotionDiscountStrategy 类代码...

// 策略的创建
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 查表替代根据 type 分支判断。

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

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 类中转移到了工厂类中，实际上并没有真正将它移除。

问题与解决思路

假设有这样一个需求，希望写一个小程序，实现对一个文件进行排序的功能。文件中只包含整型数，并且，相邻的数字通过逗号来区隔。你可能会说，这不是很简单嘛，只需要将文件中的内容读取出来，并且通过逗号分割成一个一个的数字，放到内存数组中，然后编写某种排序算法（比如快排），或者直接使用编程语言提供的排序函数，对数组进行排序，最后再将数组中的数据写入文件就可以了。

但是，如果文件很大呢？比如有 10GB 大小，因为内存有限（比如只有 8GB 大小），我们没办法一次性加载文件中的所有数据到内存中，这个时候，我们就要利用外部排序算法。

如果文件更大，比如有 100GB 大小，我们为了利用 CPU 多核的优势，可以在外部排序的基础之上进行优化，加入多线程并发排序的功能，这就有点类似单机版的 MapReduce。如果文件非常大，比如有 1TB 大小，即便是单机多线程排序，这也算很慢了。这个时候，我们可以使用真正的 MapReduce 框架，利用多机的处理能力，提高排序的效率。

代码实现与分析

我先用最简单直接的方式将它实现出来。在下面的代码实现中，我只给出了跟设计模式相关的骨架代码，并没有给出每种排序算法的具体代码实现：

public class Sorter 
{
    private static final long GB = 1000 * 1000 * 1000;

    public void sortFile(String filePath) 
    {
        // 省略校验逻辑
        File file = new File(filePath);
        long fileSize = file.length();
        if (fileSize < 6 * GB) 
        { 
            // [0, 6GB)
            quickSort(filePath);
        } 
        else if (fileSize < 10 * GB) 
        { 
            // [6GB, 10GB)
            externalSort(filePath);
        } 
        else if (fileSize < 100 * GB) 
        { 
            // [10GB, 100GB)
            concurrentExternalSort(filePath);
        } 
        else 
        { 
            // [100GB, ~)
            mapreduceSort(filePath);
        }
    }

    private void quickSort(String filePath) 
    {
        // 快速排序
    }

    private void externalSort(String filePath) 
    {
        // 外部排序
    }

    private void concurrentExternalSort(String filePath) 
    {
        // 多线程外部排序
    }

    private void mapreduceSort(String filePath) 
    {
        // 利用 MapReduce 多机排序
    }
}

public class SortingTool 
{
    public static void main(String[] args) 
    {
        Sorter sorter = new Sorter();
        sorter.sortFile(args[0]);
    }
}

在编码规范那一部分我们讲过，函数的行数不能过多，最好不要超过一屏的大小。所以，为了避免 sortFile() 函数过长，我们把每种排序算法从 sortFile() 函数中抽离出来，拆分成 4 个独立的排序函数。

如果只是开发一个简单的工具，那上面的代码实现就足够了。毕竟，代码不多，后续修改、扩展的需求也不多，怎么写都不会导致代码不可维护。但是，如果我们是在开发一个大型项目，排序文件只是其中的一个功能模块，那我们就要在代码设计、代码质量上下点儿功夫了。只有每个小的功能模块都写好，整个项目的代码才能不差。

在刚刚的代码中，我们并没有给出每种排序算法的代码实现。实际上，如果自己实现一下的话，你会发现，每种排序算法的实现逻辑都比较复杂，代码行数都比较多。所有排序算法的代码实现都堆在 Sorter 一个类中，这就会导致这个类的代码很多。而在编码规范那一部分中，我们也讲到，一个类的代码太多也会影响到可读性、可维护性。除此之外，所有的排序算法都设计成 Sorter 的私有函数，也会影响代码的可复用性。

代码优化与重构

只要掌握了我们之前讲过的设计原则和思想，针对上面的问题，即便我们想不到该用什么设计模式来重构，也应该能知道该如何解决，那就是将 Sorter 类中的某些代码拆分出来，独立成职责更加单一的小类。实际上，拆分是应对类或者函数代码过多、应对代码复杂性的一个常用手段：

public interface ISortAlg 
{
    void sort(String filePath);
}

public class QuickSort implements ISortAlg 
{
    @Override
    public void sort(String filePath) 
    {
        //...
    }
}

public class ExternalSort implements ISortAlg 
{
    @Override
    public void sort(String filePath) 
    {
        //...
    }
}

public class ConcurrentExternalSort implements ISortAlg 
{
    @Override
    public void sort(String filePath) 
    {
        //...
    }
}

public class MapReduceSort implements ISortAlg 
{
    @Override
    public void sort(String filePath) 
    {
        //...
    }
}

public class Sorter 
{
    private static final long GB = 1000 * 1000 * 1000;

    public void sortFile(String filePath) 
    {
        // 省略校验逻辑
        File file = new File(filePath);
        long fileSize = file.length();
        ISortAlg sortAlg;
        if (fileSize < 6 * GB) 
        { 
            // [0, 6GB)
            sortAlg = new QuickSort();
        } 
        else if (fileSize < 10 * GB) 
        { 
            // [6GB, 10GB)
            sortAlg = new ExternalSort();
        } 
        else if (fileSize < 100 * GB) 
        { 
            // [10GB, 100GB)
            sortAlg = new ConcurrentExternalSort();
        } 
        else 
        { 
            // [100GB, ~)
            sortAlg = new MapReduceSort();
        }
        sortAlg.sort(filePath);
    }
}

实际上，上面的代码还可以继续优化。每种排序类都是无状态的，我们没必要在每次使用的时候，都重新创建一个新的对象。所以，我们可以使用工厂模式对对象的创建进行封装：

public class SortAlgFactory 
{
    private static final Map<String, ISortAlg> algs = new HashMap<>();

    static 
    {
        algs.put("QuickSort", new QuickSort());
        algs.put("ExternalSort", new ExternalSort());
        algs.put("ConcurrentExternalSort", new ConcurrentExternalSort());
        algs.put("MapReduceSort", new MapReduceSort());
    }

    public static ISortAlg getSortAlg(String type) 
    {
        if (type == null || type.isEmpty()) 
        {
            throw new IllegalArgumentException("type should not be empty.");
        }
        return algs.get(type);
    }
}

public class Sorter 
{
    private static final long GB = 1000 * 1000 * 1000;

    public void sortFile(String filePath) 
    {
        // 省略校验逻辑
        File file = new File(filePath);
        long fileSize = file.length();
        ISortAlg sortAlg;
        if (fileSize < 6 * GB) 
        { 
            // [0, 6GB)
            sortAlg = SortAlgFactory.getSortAlg("QuickSort");
        } 
        else if (fileSize < 10 * GB) 
        { 
            // [6GB, 10GB)
            sortAlg = SortAlgFactory.getSortAlg("ExternalSort");
        } 
        else if (fileSize < 100 * GB) 
        { 
            // [10GB, 100GB)
            sortAlg = SortAlgFactory.getSortAlg("ConcurrentExternalSort");
        } 
        else 
        { 
            // [100GB, ~)
            sortAlg = SortAlgFactory.getSortAlg("MapReduceSort");
        }
        sortAlg.sort(filePath);
    }
}

经过上面两次重构之后，现在的代码实际上已经符合策略模式的代码结构了。我们通过策略模式将策略的定义、创建、使用解耦，让每一部分都不至于太复杂。不过，Sorter 类中的 sortFile() 函数还是有一堆 if-else 逻辑。如果你特别想将 if-else 分支判断移除掉，那也是有办法的。实际上，这也是基于查表法来解决的，其中的“algs”就是“表”：

public class Sorter 
{
    private static final long GB = 1000 * 1000 * 1000;
    private static final List<AlgRange> algs = new ArrayList<>();
    static 
    {
        algs.add(new AlgRange(0, 6*GB, SortAlgFactory.getSortAlg("QuickSort")));
        algs.add(new AlgRange(6*GB, 10*GB, SortAlgFactory.getSortAlg("ExternalSort")));
        algs.add(new AlgRange(10*GB, 100*GB, SortAlgFactory.getSortAlg("ConcurrentExternalSort")));
        algs.add(new AlgRange(100*GB, Long.MAX_VALUE, SortAlgFactory.getSortAlg("MapReduceSort")));
    }

    public void sortFile(String filePath) 
    {
        // 省略校验逻辑
        File file = new File(filePath);
        long fileSize = file.length();
        ISortAlg sortAlg = null;
        for (AlgRange algRange : algs) 
        {
            if (algRange.inRange(fileSize)) 
            {
                sortAlg = algRange.getAlg();
                break;
            }
        }
        sortAlg.sort(filePath);
    }

    private static class AlgRange 
    {
        private long start;
        private long end;
        private ISortAlg alg;

        public AlgRange(long start, long end, ISortAlg alg) 
        {
            this.start = start;
            this.end = end;
            this.alg = alg;
        }

        public ISortAlg getAlg() 
        {
            return alg;
        }

        public boolean inRange(long size) 
        {
            return size >= start && size < end;
        }
    }
}

现在的代码实现就更加优美了。我们把可变的部分隔离到了策略工厂类和 Sorter 类中的静态代码段中。当要添加一个新的排序算法时，我们只需要修改策略工厂类和 Sort 类中的静态代码段，其他代码都不需要修改，这样就将代码改动最小化、集中化了。

对于 Java 语言来说，我们可以通过反射来避免对策略工厂类的修改。具体是这么做的：我们通过一个配置文件或者自定义的 annotation 来标注都有哪些策略类；策略工厂类读取配置文件或者搜索被 annotation 标注的策略类，然后通过反射动态地加载这些策略类、创建策略对象；当我们新添加一个策略的时候，只需要将这个新添加的策略类添加到配置文件或者用 annotation 标注即可。

设计原则和思想其实比设计模式更加普适和重要，掌握了代码的设计原则和思想，我们甚至可以自己创造出来新的设计模式。