深入浅出——Strategy策略模式

策略模式有两点主要思想，其一是将变化部分与不变部分分离，其二是面向接口编程而不是面向实现编程，以《Head First设计模式》中的例子，可以比较清晰的阐述清楚以上两点。

例如我们我们收到一个客户要求，需要生产各种鸭子（绿头鸭、唐老鸭、可达鸭…），我们自然而然的就想到了，首先设计一个鸭子的超类，其具有一些鸭子共有的属性以及行为，然后让其他的子类对其进行继承，但此时遇到一个问题，并非所有的鸭子都会飞，并且每一种鸭子的叫声也不一样。为了解决这个问题，我们只能不断的改写每一个鸭子子类中的方法，更大的问题是，当有新的鸭子产品继承自鸭子超类时，都要被迫检查可能需要覆盖的fly()和quark()。

然后我们又想到，能否创建两个接口Flyable和Quackable，然后让鸭子的子类根据实际情况去继承这些接口们，然后各自实现接口的功能。
显然，这也不是什么好主意，为了实现每一种接口，需要重复的代码更多，那如何从根本上解决这一问题呢？

鸭子类中会发生变化的只有fly()和quack()这两类行为，策略设计模式中有这样一条设计原则，**找到应用中可能需要变化之处，把它们独立出来，不要和哪些不需要变化的代码混在一起。**于是，我们将这两种行为从鸭子类中分离出来。

接下来又是新的问题，这两种被分离出来的行为要以何种的形式存在呢，以及鸭子类如何与这两类行为发生联系？此时就引出了第二条设计原则，**针对接口编程，而不是针对实现编程。**这句话更确切的说是“变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口，如此，只要是具体实现此超类型的类所产生的对象，都可以指定给这个变量”

在Duck类中，我们利用接口代表每一种行为，而不是将行为的实现（即函数）绑定其中。既然在Duck类中，我们用接口代表每种行为，那么被分离出来的行为当然是以接口的形式存在，比如FlyBehavior和QuackBehavior。然后不同飞的方式（包括不能飞），不同叫的方式都可以作为这两种接口的实现类，然后让Duck中的行为接口指向这些实现类即可

所以话说回来，到底什么是策略模式呢？以及在何时使用该模式呢？我的理解是当完成一件事情可以有多种策略（或者说成方法更好理解）时，就可以使用策略模式，其主要步骤是将该行为分离抽象为接口，完成该方法的不同策略实现这个接口，然后在拥有该行为的类中声明该接口的变量，指向实际的类。

举个例子，在学Java基础时，我们一定对Comparator以及Comparable这两个比较器接口不陌生，但是身边很多同学不理解这两个接口到底有什么区别。我个人的理解，Comparable就像是Flyable或者Quackable这类接口，我们需要为每一种需要比较的类写其实现，行为的实现还是和类牢牢的绑定在一起。而Comparator则是真真切切使用了策略模式的思想，关于比较这一行为，有不同的策略，拿人来说，可以以高矮进行比较，也可以拿胖瘦进行比较，我们完全可以通过实现Comparator这个接口，实现这些策略，然后传入到Sort类中进行比较，这大大提高了程序的弹性，这也就是策略模式的魅力所在

public interface Comparable<T> {
    int compareTo(T o);
}

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