设计模式：策略模式，避免冗长的if-else/switch分支判断代码

最新推荐文章于 2023-11-09 11:11:15 发布

OceanStar的学习笔记

最新推荐文章于 2023-11-09 11:11:15 发布

阅读量1.8k

点赞数 2

分类专栏：计算机理论与基础文章标签：策略模式 java 开发语言

原文链接：https://time.geekbang.org/

版权

计算机理论与基础专栏收录该内容

310 篇文章 69 订阅

订阅专栏

策略模式的原理和实现

策略模式，英文全称是 Strategy Design Pattern。定义为：定义彝族算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式可以使算法的变化独立于使用它们的客户端（这里的客户端指的是使用算法的代码）

我们知道，工厂模式是解耦对象的创建和使用，观察者模式是解耦观察者和被观察者。策略模式解耦策略的定义、创建、使用者三部分

策略的定义

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

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);
		 //...
	 }
}

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

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

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

我们先通过一个例子来看下，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 HashMa
	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.getDiscountStra
		return discountStrategy.calDiscount(order);
	}
}

重构之后的代码就没有了if-else分支判断语句了。实际上，这得益于策略工厂类。在工厂类中，我们用Map来缓存策略，根据type直接从Map中获取对应的策略，从而避免if-else分支判断逻辑。它本质是借助“查表法”，根据type查表（代码中的strategies 就是表）替代根据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 类中转移到了工厂类中，实际上并没有真正将它移除。这时仍然可以用查表法，只不过存储的不再是实例，而是class，使用时获取对应的class，再通过反射创建实例

如何实现一个支持给不同大小文件排序的小程序

问题与解决思路

假设有这样一个需求，希望写一个小程序，实现对一个文件进行排序的功能。文件中只包含整形数，并且，相邻的数据通过逗号来分隔。

这时可以将文件中的内容读取出来，并且通过逗号分割成一个一个的数字，放到内存数组中，然后编写某种排序算法，或者直接使用编程语言提供的排序函数，对数组进行排序，最后再将数组中的数据写入文件就可以了。

但是，如果文件很大呢？比如有 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]);
	}
}

问题是，每种排序算法的实现逻辑都比较复杂，代码行数都比较多。所有排序算法的代码实现都堆在 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 逻辑分支不多、也不复杂，这样写完全没问题。但如果你特别想将 if-else 分支判断移除掉，那也是有办法的。如下：

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 类中的静态代码段，其他代码都不需要修改，这样就将代码改动最小化、集中化了。

总结

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

策略模式用来解耦策略的定义、创建、使用。实际上，一个完整的策略模式就是由这三个部分组成的。

策略类的定义比较简单，包含一个策略接口和一组实现这个接口的策略类。
策略的创建由工厂类来完成，封装策略创建的细节。
策略模式包含一组策略可选，客户端代码如何选择使用哪个策略，有两种确定方法：编译时静态确定和运行时动态确定。其中，“运行时动态确定”才是策略模式最典型的应用场景。

除此之外，我们还可以通过策略模式来移除 if-else 分支判断。实际上，这得益于策略工厂类，更本质上点讲，是借助“查表法”，根据 type 查表替代根据 type 分支判断。

一提到 if-else 分支判断，有人就觉得它是烂代码。如果 if-else 分支判断不复杂、代码不多，这并没有任何问题，毕竟 if-else 分支判断几乎是所有编程语言都会提供的语法，存在即有理由。遵循 KISS 原则，怎么简单怎么来，就是最好的设计。非得用策略模式，搞出 n多类，反倒是一种过度设计。

一提到策略模式，有人就觉得，它的作用是避免 if-else 分支判断逻辑。实际上，这种认识是很片面的。策略模式主要的作用还是解耦策略的定义、创建和使用，控制代码的复杂度，让每个部分都不至于过于复杂、代码量过多。除此之外，对于复杂代码来说，策略模式还能让其满足开闭原则，添加新策略的时候，最小化、集中化代码改动，减少引入 bug 的风险。

实际上，设计原则和思想比设计模式更加普适和重要。掌握了代码的设计原则和思想，我们能更清楚的了解，为什么要用某种设计模式，就能更恰到好处地应用设计模式。

OceanStar的学习笔记

关注

2
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
设计模式：策略模式，避免冗长的if-else/switch分支判断代码

策略模式的原理和实现策略模式，英文全称是 Strategy Design Pattern。定义为：定义彝族算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式可以使算法的变化独立于使用它们的客户端（这里的客户端指的是使用算法的代码）我们知道，工厂模式是解耦对象的创建和使用，观察者模式是解耦观察者和被观察者。策略模式解耦策略的定义、创建、使用者三部分策略的定义策略的定义比较简单，包含一个策略接口和一组实现这个接口的策略类。因为所有的策略类都实现相同的接口，所以，客户端代码基于接口而非实现编程，
复制链接

扫一扫