初入职场的小黄不懂策略模式，差点被开除！

1. 背景

小黄是一名刚毕业的大学生，初入职场，憧憬着书写优美的代码。

这一天，领导找到小黄，对小黄说：小黄呀，你刚来公司，对公司业务还不是那么熟悉，这里有一个小需求，你去做一下吧。

小黄回到了自己的工位上，点开了需求文档：

公司新上了一批宠物，需要根据其特征进行排序，优化客户的使用体验
- 猪：根据吃的多少排序
- 狗：根据叫的分贝排序
- 猫：根据体重进行排序

小黄看完了需求，脸上洋溢着快乐的笑容，不知道的还以为中彩票了。

小黄心想：一个简简单单的排序，这也算需求，看我把他拿下。

殊不知，这一个简简单单的排序，差点让小黄摊上大事。

2. 初步实现

小黄的方案：

创建三个类
- 猪：public class Pig {...}
- 狗：public class Dog {...}
- 猫：public class Cat {...}
创建一个Sorter类，包含三个方法
- 第一个方法：public void pigSort(Pig[] array) {...}
- 第二个方法：public void dogSort(Pig[] array) {...}
- 第三个方法：public void catSort(Pig[] array) {...}

测试类

public class Main {
    public static void main(String[] args) {
        Dog[] array = new Dog[]{new Dog(3), new Dog(1), new Dog(2)};
        Sorter sorter = new Sorter();
        sorter.dogSort(array);
        for (Dog dog : array) {
            System.out.print(dog + " ");
        }
    }
}

小黄看了看测试结果，一切正常。心想：这就是公司需求嘛，也太简单了吧。

小黄拿着自己写的代码去找领导，准备向领导展示自己在这么短的时间内解决掉这个需求。

领导看了看小黄写的代码，提出了几个问题：

如果我现在有上千批宠物，你每一个宠物都弄一个Sort方法吗？
如果我每一个宠物都有2种特征，分别排序，你是不是还要给我写一个方法？
你代码的可扩展性、可维护性有吗？

自己好好去看看设计模式中的策略模式，去认真修改一下自己的代码。

小黄懵了，没想到信心满满的代码，居然错误这么多。

小黄仔细想了想，确实自己大量的使用 if else 会造成扩展性降低，于是上网搜了一个叫“爱敲代码的小黄”的公众号，有一篇讲解策略模式的文章，认认真真的看了下。

3. 策略模式下的实现

策略模式最大的优点就是避免了大规模的if else 判断

策略模式有一个公共的 Strategy 接口，通过该接口，封装着实现同一种事情的不同方法

比如：拿上述小黄的例子来说

同一种事情：排序
不同的方法：每个动物排序的特征不同

我们来画出整个需求的结构图：

策略模式.png

我们首先要创建一个公共接口，名字叫 Comparator，作为我们所有宠物排序的公共接口
- 使用的原因：每个宠物的属性不同，我们需要使用泛型来传值
```
public interface Comparator<T> {
    int compare(T o1, T o2);
}
```

实现公共接口的三个实现类(这里只写猫的，其他类似)：

猫

public class CatWeightComparator implements Comparator<Cat> {
    @Override
    public int compare(Cat o1, Cat o2) {
        if (o1.weight > o2.weight) {
            return 1;
        } else if (o1.weight < o2.weight) {
            return -1;
        } else {
            return 0;
        }
    }
}

狗

public class DogSoundComparator implements Comparator<Dog> {...}

猪

public class PigEatComparator implements Comparator<Pig> {...}

实现我们的主要类：Sorter

作用：主函数只需要告知 Sorter 我们当前使用的哪个数组及哪个实现类既可以完成排序

public class Sorter<T> {
    // arrry：传进来的数组
    // comparator：比较器的类型
    public void sort(T[] array, Comparator<T> comparator) {
        for (int i = 0; i < array.length - 1; i++) {
            for (int j = 0; j < array.length - i - 1; j++) {
                if (comparator.compare(array[j], array[j + 1]) > 0) {
                    T temp = array[j];
                    array[j] = array[j + 1];
                    array[j + 1] = temp;
                }
            }
        }
    }
}

实现我们的测试类Main

public class Main {
    public static void main(String[] args) {
        Dog[] array = new Dog[]{new Dog(3), new Dog(1), new Dog(2)};
        Sorter<Dog> sorter = new Sorter<>();
        sorter.sort(array, new DogSoundComparator());
        for (Dog dog : array) {
            System.out.println(dog);
        }
        // 输出为：Dog{food=1} Dog{food=2} Dog{food=3}
    }
}

至此，我们来看小黄领导提出的三个问题

如果我现在有上千批宠物，你每一个宠物都弄一个Sort方法吗？
如果我每一个宠物都有2种特征，分别排序，你是不是还要给我写一个方法？
你代码的可扩展性、可维护性有吗？

我们观察如上的架构图可以发现，对于Sorter方法，我们从来不会更改其代码，当我们需要增添一个特征或者宠物时，我们采取的是增加一个实现类的操作

无论有多少宠物、多少特征，我们只需要在容器内增加实现类，让外部Sorter调用即可，极大的增加了代码的可扩展性

4. 总结

策略模式真正核心的地方在于：实现同一种事情使用不同的方式，当遇到这类问题，我们就可以想想能不能采取策略模式进行解决。

小黄看完之后，连夜改善了自己的代码，第二天去找领导

领导对这版代码颇为赞同，对小黄说：这一版代码实现的不错，继续加油。

小黄刚想走，领导喊住了他，小黄以为自己代码又出错了，没想到领导问：小黄，你在哪这么快学会的设计模式？

小黄舒了口气，小声的说道：有一个“爱敲代码的小黄”的公众号，他最近正在写设计模式的专题，我看完就会了

领导说：那我也去关注下，正好最近没事做，去看看这小子写的怎么样

小黄的职场之路未完......