设计模式系列----策略模式的理解，以及为什么要有上下文

其实策略模式是非常的简单易懂的，因为他和Java中封装太像了，其实策略模式就是对封装的进一步优化，使得封装的更加彻底，加强高内聚、低耦合的效果。

策略模式在Java中的应用非常广泛，写出优秀代码基本离不开策略模式，这里我先替大家提出一个疑问：
为什么要加一个上下文的类呢，直接调用代码不是更加简洁吗？

带着疑问，我们往下看：

策略模式的功能，就是定义了一系列的算法，这些算法定义着公共的接口，所以它们之间可以相互替换。这使得我们在开发过程中，若有新的策略需要扩展时，程序变的很容易开发。

就以旅游的例子为例，去旅游的方式有很多种，可以骑车，开车，走路去旅游，这些方式都相当于是一种算法，来看例子。

定义公共的旅游策略抽象类：

定义 具体的骑自行车去旅游的策略 继承公共旅游策略类

定义 具体的开车去旅游的策略 继承公共旅游策略类

如果不使用策略模式：

直到这里都还是非常常见的继承套路，日常我们就是这样写代码的，接下来我们调用就是如下调用：

看起来完全没毛病对吧，这是在业务简单的情况下。
那如果突然加了一个需求，旅游前需要先提供核酸检测证明，并且职业还必须是程序员，才能去旅行呢？

正常情况下，没办法，只能在调用前判断一下，伪代码如下：

public static void main(String[] args) {
     
    //骑自行车去旅游
    if("没有核酸证明"){
     
        return "现场做核酸证明";
    }
    if("职业不是程序员"){
     
        return "不准旅游";
    }
    TravelByBikeStrategy travelByBikeStrategy = new TravelByBikeStrategy();
    travelByBikeStrategy.travel();
}

这样写怎么看怎么难受。完全与优雅相悖。

如果使用策略模式

如果是策略模式，会多一个上下文的统一调用类如下：

我们调用就是通过Context上下文类进行如下调用：

如果也是要加新需求，旅游前需要先提供核酸检测证明，并且职业还必须是程序员，才能去旅行，在策略模式中，不会直接在调用时进行判断，而是在上下文类中进行判断，伪代码如下：

而在业务调用是，就不用再进行判断了，如下：

可能没细想的同学会脱口而出，这跟不使用策略模式有什么区别？？？

第一，是代码优雅的问题，很明显使用策略模式后，客户端只需要调用旅游策略就行，不需要关心其他条件。
第二，在实际开发中，较为常见的情况就是：上层的调用需要与接口之间有一定的交互。交互的可能是一些属性，或是一些方法。这样的交互往往会让接口变的难以调用；于是上下文的引入就是势在必行。将相关的属性或一些公共的方法封装到上下文中，让上下文去和接口进行复杂的交互。而上层的调用只需要跟上下文打交道就可以。

总而言之、言而总之，就是上下文封装调用才是策略模式的精髓。

----我是“道祖且长”，一个在互联网“苟且偷生”的Java程序员