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 接口，通过该接口，封装着实现同一种事情的不同方法

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

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

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

1. 我们首先要创建一个公共接口，名字叫 Comparator，作为我们所有宠物排序的公共接口

   • 使用<t>的原因：每个宠物的属性不同，我们需要使用泛型来传值</t>

   public interface Comparator<T> {
       int compare(T o1, T o2);
   }

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

   • 猫

     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> {...}

3. 实现我们的主要类：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;
                   }
               }
           }
       }
   }

4. 实现我们的测试类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}
       }
   }

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

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

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

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

4. 总结

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

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

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

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

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

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

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