设计模式之：策略模式

声明

[版权申明]非商业目的注明出处可自由转载
博文地址：https://blog.csdn.net/ShuSheng0007/article/details/86644481
出自：shusheng007


前言

人在IT江湖飘，不懂设计模式咋装X？

我们这个社会上的事情大概率都符合八二法则，软件领域也一样。例如你学习一门编程语言，工作中常用的类来来回回也就那么几十个。那么多设计模式，最常被人使用的也就那么几种，所以我们在做事情的时候应该首先着眼于那20%。

策略模式算是设计模式中简单而又常用的了。

定义

策略模式定义了一系列的算法，并将每一个算法封装起来，使他们可以相互替换。

使用场景

当你写代码的时候发现一个操作有好多种实现方法，而你需要根据不同的情况使用if-else等分支结构来确定使用哪种实现方式的时候，想一想这个模式。

如何实现

业务场景

2017年的2月14号，王二狗和牛翠花约好在天津之眼约定终身，二狗打扮一番后准备出发，此时问题来了：是坐公交去呢，还是打滴滴快车呢？天气看起来也不错，要不骑共享单车吧，省钱还锻炼身体。

对应到编程领域就是：目前有三种策略可以实现一个特定的目的，使用何种策略取决于调用者（客户端）

普通实现

如果我们正常写代码，平时也应该这样，首先保证把功能正确的实现了，然后慢慢重构，设计模式都是在不断的重构当中应用的。 王二狗会调用会调用goToTianJinEye()方法，根据自己的实际情况，选择某一种出行方式。

public class TrafficFeeCalculator {
public int goToTianJinEye(String way, int distance) {
int trafficFee = 0;
switch (way) {
case "bus":
if (distance < 10)
trafficFee = 4;
else
trafficFee = 6;
break;
case "didi":
if(distance<3)
trafficFee = 8;
else
trafficFee=8+(distance-3)*3;
break;
case "sharedBicyle":
trafficFee = 2;
break;
default:
break;
}
return trafficFee;
}
}


那么这么写有什么弊端呢？

• 第一：每一种出行方式的交通花费的计算方式都写在了TrafficFeeCalculator类中，这个类承担的职责较多，违反了单一职责原则。

• 第二：假如王二狗突然想自己开车去，那就需要修改goToTianJinEye这个方法了。违反了开闭原则。

使用策略模式

以上的场景非常适合使用策略模式，将多种不同的实现算法封装，然后客户端根据不同策略分别调用相应的算法。

第一步：封装不同的实现算法
首先定义一个策略接口，规定算法的同一操作

public interface CalculateStrategy {
int calculateTrafficFee(int distance);
}


第二步：封装各个算法

//乘坐公交车算法
public class ByBus implements CalculateStrategy {
@Override
public int calculateTrafficFee(int distance) {
return distance<10?4:6;
}
}
//乘坐滴滴快车算法
public class ByDiDiExpress implements CalculateStrategy {
@Override
public int calculateTrafficFee(int distance) {
return distance<3?8:(8+(distance-3)*3);
}
}
//骑共享单车算法
public class BySharedBicycle implements CalculateStrategy {
@Override
public int calculateTrafficFee(int distance) {
return 2;
}
}


第三步：使用算法

public class TrafficFeeCalculator {
...
public int goToTianJinEye(CalculateStrategy strategy,int distance){
return strategy.calculateTrafficFee(distance);
}
}


第四步：客户端调用
根据情况，构建相应的算法类实例，传入计算器计算即可

public static void main(String[] args) {
TrafficFeeCalculator calculator=new TrafficFeeCalculator();
System.out.println(String.format("乘坐公交车到天津之眼的花费为：%d块人民币",
calculator.goToTianJinEye(new ByBus(),10)));
System.out.println(String.format("乘坐滴滴快车到天津之眼的花费为：%d块人民币",
calculator.goToTianJinEye(new ByDiDiExpress(),10)));
System.out.println(String.format("骑共享单车到天津之眼的花费为：%d块人民币",
calculator.goToTianJinEye(new BySharedBicycle(),10)));
}


输出为：

乘坐公交车到天津之眼的花费为：6块人民币
乘坐滴滴快车到天津之眼的花费为：29块人民币
骑共享单车到天津之眼的花费为：2块人民币


二狗为了早点见到自己心爱的牛翠花，最终选择了滴滴快车，贵是贵了点，但是快！

优缺点

• 优点：降低了算法类的职责，使各个算法可以独立变化并互相替换。而且使得增加新的算法变的很容易，降低了对原有系统的侵入，最终使得程序可扩展可维护性增强。

• 缺点：所有设计模式的通病，类增多了，程序从局部来看变的更复杂了。

总结

是不是感觉讲设计模式的文章都有一个特点，使用了设计模式反而比不使用设计模式使程序看起来更加复杂，而不是更加简单。那是因为每篇文章的示例都是无实际使用意义的示例代码，实际情况是程序非常复杂才需要使用到设计模式。一个大型程序是不断迭代出来的，一开始肯定不长那样，程序员日常接到一个开发任务也不要过多的想，这个我应该用个什么设计模式呀？先把功能实现了，然后回头看看有没有遵循面向对象编程6大原则，如果没有想想怎么改进，然后设计模式就登场了。。。