概述
上篇文章,主要介绍了策略模式的原理和实现,以及如何利用策略模式来移除 if-esle 或者 switch 分支判断逻辑。本章结合 "给文件排序" 的例子,来详细讲下策略模式的设计意图和应用场景。
此外,我还会通过进一步分析、重构,给你展示一个设计模式是如何 "创造" 出来的。通过本章的学习,你会发现:设计原则和思想其实比设计模式更加普适和重要,掌握了代码的设计原则和思想,我们甚至可以自己创造出来新的设计模式。
问题与思路
假设有这样一个需求,希望写一个程序,实现对一个文件进行排序。文件中只包含整型数,并且相邻的数字通过都好来区隔。若由你编写这样一个程序,你会如何来实现呢?
你可能会说,这不是很简单嘛,只需要将文件中的内容读出来,通过都好分割成一个个的数字,放到内存数组中,然后编写某种算法(比如快速排序),或者直接使用编程语言提供的排序函数,对数组进行排序,然后再讲数组中的数据写入文件就可以了。
但是,若文件很大呢?比如有 10G,因为内存有限(比如只有 8G),没有办法一次性将所有数据加载到内存,这是就要利用外部排序算法了。
如果文件更大,比如有 100G,为了利用 CPU 多核的优势,可以在外部排序的基础上进行优化,加入多线程并发排序的功能,这就有点类似单机版的 MapReduce 了。
如果文件非常大,有 1TB ,即便是单机多线程排序,这也算很慢了。这个时候,可以使用真正的 MapReduce 框架,利用多机的能力,提高排序效率。
代码实现与分析
思路讲完了,接下来看一下如何将解决思路翻译成代码实现。
我们先用最简单的方式将它实现出来,所以,在下面的代码中,只给出了跟设计模式相关的骨架代码,并没有给出每种排序算法的具体实现。
java
public class Sorter {
private static final long GB = 1024 * 1024 * 1024;
public void sortFiles(String filePath) {
// 省略校验...
File file = new File(filePath);
long fileSize = file.length();
if (fileSize < 6 * GB) { // [0, 6G]
quickSort(filePath);
} else if (fileSize < 10 * GB) { // [6G, 10G]
externSort(filePath);
} else if (fileSize < 100 * GB) { // [10G, 100G]
concurrentExternalSort(filePath);
} else { // [1000G, ~]
mapreduceSort(filePath);
}
}
private void quickSort(String filePath) {
// 快速排序...
}
private void externSort(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.sortFiles(args[0]);
}
}
在编码规范 章节,我们讲过,函数的函数不能太多,最好不要超过一屏的大小。所以,为了避免 sortFiles()
函数过长,我们把每种排序算法从 sortFiles()
函数中抽离出来,拆分成 4 个独立的排序函数。
如果只是开发一个简单的工具,那上面的代码实现就足够了。毕竟,代码不多,后续修改、扩展的需求也不多,怎么写都不会导致代码不可维护。但是,如果在开发一个大型项目,排序文件只是其中的一个功能模块,那就要在代码设计、代码质量上下点功夫了。每个小的功能模块都写好,整个项目的代码才能不差。
在刚刚的代码中,并位给出每中排序算法的代码实现。实际上,如果实现一下的话,你会发现每种排序算法的实现逻辑都比较复杂,代码行数都比较多。所有排序算法的代码都堆在一个 Sorter
类中,就会导致这个类的代码很多。而在编码规范 章节,也降到,一个类的代码太多也会影响到可读性、可维护性。此外,所有的排序算法目前都是 private 的,也会影响代码的可复用性。
代码重构与优化
只要掌握了之前讲过的设计原则和设计思想,即使想不到该用什么设计模式来重构,也应该能知道如何优化。就是将 Sorter
类中的某些代码拆分出来,独立成职责更加单一的小类。实际上,拆分是应对类或函数代码过多、应对代码复杂的一个常用手段。按照这个解决思路,我们对代码进行重构。重构之后的代码如下所示:
java
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 = 1024 * 1024 * 1024;
public void sortFiles(String filePath) {
// 省略校验...
File file = new File(filePath);
long fileSize = file.length();
ISortAlg sortAlg;
if (fileSize < 6 * GB) { // [0, 6G]
sortAlg = new QuickSort();
} else if (fileSize < 10 * GB) { // [6G, 10G]
sortAlg = new ExternalSort();
} else if (fileSize < 100 * GB) { // [10G, 100G]
sortAlg = new ConcurrentExternalSort();
} else { // [1000G, ~]
sortAlg = new MapReduceSort();
}
sortAlg.sort(filePath);
}
}
经过拆分后,每个类的代码不会太多,每个类的逻辑不会太复杂,代码可读性、可维护性提高了。此外,将排序算法设计成独立的力,跟具体的业务逻辑(代码中的 if-else 那部分逻辑)解耦,也让排序算法能够复用。这一步实际上就是策略模式的第一步,将策略模式的定义分离出来。
接下来,可以继续优化。每种排序类都是无状态的,我们没必要每次使用时都重新创建一个对象。所以,可以使用工厂模式对对象的创建进行封装。按照这个思路,对代码进行重构。重构之后的代码如下所示:
java
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 must not be null");
}
return algs.get(type);
}
}
public class Sorter {
private static final long GB = 1024 * 1024 * 1024;
public void sortFiles(String filePath) {
// 省略校验...
File file = new File(filePath);
long fileSize = file.length();
ISortAlg sortAlg;
if (fileSize < 6 * GB) { // [0, 6G]
sortAlg = SortAlgFactory.getSortAlg("QuickSort");
} else if (fileSize < 10 * GB) { // [6G, 10G]
sortAlg = SortAlgFactory.getSortAlg("ExternalSort");
} else if (fileSize < 100 * GB) { // [10G, 100G]
sortAlg = SortAlgFactory.getSortAlg("ConcurrentExternalSort");
} else { // [1000G, ~]
sortAlg = SortAlgFactory.getSortAlg("MapReduceSort");
}
sortAlg.sort(filePath);
}
}
经过两次重构之后,现在的代码实际上已经符合策略模式的代码结构了。通过策略模式将策略的定义、创建、使用解耦,让每一部分代码都不至于太复杂。不过 Sorter
类中的 sortFiles()
函数还有一堆 if-else 逻辑。目前,这里的 if-else 逻辑分支不多、也不复杂,这样写完全没有问题。但是如果你想将 if-else 分支判断移除掉,那也是有办法的。下面是代码实现,你一看就能明白。实际上,这也是基于查表法来解决的,其中的 algs
就是 "表"。
java
public class Sorter {
private static final long GB = 1024 * 1024 * 1024;
private static final List<AlgRange> algs = new ArrayList<>();
static {
algs.add(new AlgRange(0, 6*GB, SortAlgFactory.getSortAlg("QuickSort")));
algs.add(new AlgRange(6, 10*GB, SortAlgFactory.getSortAlg("ExternalSort")));
algs.add(new AlgRange(10, 100*GB, SortAlgFactory.getSortAlg("ConcurrentExternalSort")));
algs.add(new AlgRange(100, Long.MAX_VALUE, SortAlgFactory.getSortAlg("MapReduceSort")));
}
public void sortFiles(String filePath) {
// 省略校验...
File file = new File(filePath);
long fileSize = file.length();
ISortAlg sortAlg = null;
for (AlgRange algRange : algs) {
if (algRange.isRange(fileSize)) {
sortAlg = algRange.getSortAlg();
break;
}
}
if (sortAlg == null) {
throw new RuntimeException("No sort algorithm");
}
sortAlg.sort(filePath);
}
private static class AlgRange {
private long start;
private long end;
private ISortAlg sortAlg;
public AlgRange(long start, long end, ISortAlg sortAlg) {
this.start = start;
this.end = end;
this.sortAlg = sortAlg;
}
public ISortAlg getSortAlg() {
return sortAlg;
}
public boolean isRange(long size) {
return size >= start && size < end;
}
}
}
现在的代码就更加优美了。我们把可变部分隔离到了策略工厂和 Sorter
类中的静态代码块中。当要添加一个新的排序算法时,只需要修改策略工厂和 Sorter
类中的静态代码块,其他代码都不需要修改。这样就将代码改动最小化、集中化了。
可能还有同学会说,即便这样,当我们添加新的排序算法时,还是需要修改代码,并不完全符合开闭原则。有什么办法让我们完全满足开闭原则呢?
对于 Java 来说,可以通过反射来避免策略工厂类的修改。具体是这样做的:通过一个配置文件或者自定义 annotation 来标注有哪些策略类;策略类工厂读取配置文件或者搜索被 annotation 标注的策略类,然后通过反射动态地加载这些策略类、创建策略类;当我们新添加一个策略的时候,只需要将这个策略类添加到配置文件或者用 annotation 标注即可。
对于 Sorter 来说,可以通过同样的方法来避免修改。 我们将文件大小区间和算法之间的对应关系放到配置文件中。当添加新的排序算法时,我们只需要改动配置文件即可,不需要改动代码。
总结
一提到 if-else 分支判断,有人就觉得那是烂代码。如果 if-else 分支判断不复杂、代码不多,这其实并没有问题,毕竟 if-else 分支判断几乎是所有编程语言都会提供的语法,存在即有理由。遵循 KISS 原则,怎么简单怎么来,就是最好的设计。非得用策略模式,搞出 n 多个类,反倒是一个过渡设计。
一提到策略模式,有人就觉得,它的作用是避免 if-else 分支判断逻辑。实际上,这种认识很片面。策略模式的主要作用还是解耦策略的定义、创建、使用,让每个部分的代码都不至于过于复杂、代码量过多。此外,对于复杂代码来说,策略模式还能让其满足开闭原则,添加新策略时,最小化、集中化代码改动,减少引入 bug 的风险。
实际上,设计原则和思想比设计模式更加普适和重要。掌握了代码的设计原则和思想,能更新的了解,为什么要用设计模式,就能更恰到好处地应用设计模式。