一文简单全面了解策略模式的使用【花几分钟轻松掌握一个知识点】_策略模式怎么知道调用哪个策略

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

public class Client {
public static void main(String[] args) {
Client client = new Client();
client.addCustomerA(“商户1”);
client.addCustomerB(“商户2”);
client.addCustomerC(“商户3”);
}

public String addCustomerA(String customer) {
    System.out.println("渠道商A入驻"+customer+"成功");
    return "success";
}


public String addCustomerB(String customer) {
    System.out.println("渠道商B入驻"+customer+"成功");
    return "success";
}

public String addCustomerC(String customer) {
    System.out.println("渠道商C入驻"+customer+"成功");
    return "success";
}

}

上述代码把策略和调用都放在了客户端中，从中不难看出，如果要在增加一个渠道商的话，则必定要修改客户端 增加新渠道商的商户入驻方法。**这样就会导致客户端变得十分臃肿复杂维护起来非常麻烦，同时也没有体现面向对象的设计思想，在实际开发中写出这样的代码怕是要被老板优化。** 那么我们该如何优化呢？


#### v1.1版本


从面向对象的角度出发，每个渠道商抽象成一个具体的对象，用一个单独的类保存其属性和行为，同时公共行为（商户入驻的行为）则用一个接口来定义，每个渠道商的类分别实现这个接口。


1. 定义公共的接口Income，该接口主要是规范了各个渠道商的行为，这里通过addCustomer方法定义了商户入驻的行为。

public interface Income {
/**
* 商户入驻
* @return
*/
String addCustomer(String customer);
}

2. 定义各个渠道商的类，这里分别定义了MerchantAIncome，MerchantBIncome以及MerchantCIncome 三个渠道商的类，并且这三个类都实现了Income接口的addCustomer方法，实现商户入驻。

public class MerchantAIncome implements Income {
@Override
public String addCustomer(String customer) {
System.out.println(“渠道商A入驻”+customer+“成功”);
return “success”;
}
}

3. 定义环境类Context，这里的环境类主要的作用就是持有一个Income对象的引用，并且该Income对象所能操作的各种行为（即各种策略）。

public class Context {
private Income income;

public Context(Income income) {
    this.income = income;
}

public String addCustomer(String customer) {
    return income.addCustomer(customer);
}

}

4. 定义调用客户端

public class Client {
public static void main(String[] args) {
new Context(new MerchantAIncome()).addCustomer(“商户1”);
new Context(new MerchantBIncome()).addCustomer(“商户2”);
new Context(new MerchantCIncome()).addCustomer(“商户3”);
}
}

##### UML图


上述代码的UML图如下图所示：这里有三个主要的角色：


1. 环境类Context
2. 抽象的策略Income接口
3. 具体的策略MerchantAIncome，MerchantBIncome以及MerchantCIncome这三个类。  
 ![在这里插入图片描述](https://img-blog.csdnimg.cn/20210609141427344.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1MzQ4MDg=,size_16,color_FFFFFF,t_70)  
 如上图所示：每个渠道商的类都是实现了一个公共的接口，该接口定义了渠道商中各种行为，包括商户入驻等等。客户端判断当前使用的是哪个渠道商。然后，生成该渠道商的实例，接着调用该渠道商的相关方法。每个渠道商自身的变化不会影响到客户端。相比较于V1.0版本而言，代码逻辑简洁了很多，增加一个渠道商的话只需要再增加一个渠道商的类，并且在客户端中加上一个判断，符合开闭原则。这里就引出了本文将要介绍的模式----策略模式。


### 策略模式


#### 定义


策略模式就是定义一系列的算法（对应本例中的一系列渠道商）， 将每个算法封装到具有公共接口的一系列策略类中（对应到本例中就是将每个渠道商封装成一个单独的类，并且这些类实现一个公共的接口），从而使它们可以相互替换并且让算法可以在不影响客户端的情况下发生变化。


#### 主要作用


从策略模式的定义中我们可以看出策略模式的主要作用就是将算法的责任和对象本身解耦，使得：


1. 算法可以独立于客户端而变化（每个渠道商内部变化不影响客户端）
2. 客户端可以根据外部条件而选择不同的策略来解决不同的问题。


#### 优点


1. 策略类之间可以自由切换
2. 易于扩展，增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码，符合“开闭原则”
3. 消除了一些 if else条件语句


#### 缺点


1. 客户端必须知道所有的策略类，并自行决定使用哪个策略类。
2. 策略模式将造成产生很多策略类，可以通过使用享元模式在一定程度上减少对象的数量。


### 策略模式与其它模式的比较


#### 与状态模式的比较


策略模式的条件选择只执行一次，而状态模式是随着实例参数（对象实例的状态）的改变不停地更改执行模式。


#### 与简单工厂模式的比较


工厂模式是创建型模式，它关注的是对象的创建，提供创建对象的接口，  
 策略模式是对象行为型模式，它关注的是行为和算法的封装。比如：出行方案中，策略模式是让你选择一种出行方式，而工厂模式是代替你构建具体的方案。


### 扩展延伸


#### v1.2版本


说完了策略模式，前面V1.1版本确实很好的运用到了策略模式，还是还不够，还是有点繁琐，客户端在调用的时候还是需要通过条件判断来决定使用哪种策略，这样还是没有干掉if和else，那么有没有什么方式可以干掉客户端的条件判断呢？答案是有的。我们可以通过枚举类来定义好各种渠道商的实例。  
 这里只需要新增一个枚举类





![img](https://img-blog.csdnimg.cn/img_convert/65dc61e842e28aa56ae088eea93007a4.png)
![img](https://img-blog.csdnimg.cn/img_convert/c8aacea5680fb5af15c3d3fa247293b8.png)

**网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。**

**[需要这份系统化资料的朋友，可以戳这里获取](https://bbs.csdn.net/topics/618545628)**


**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**

入研究，那么很难做到真正的技术提升。**

**[需要这份系统化资料的朋友，可以戳这里获取](https://bbs.csdn.net/topics/618545628)**


**一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**