策略模式是GoF23种设计模式中比较简单的了,也是常用的设计模式之一,今天我们就来看看策略模式。

实际案例

我工作第三年的时候,重构旅游路线的机票查询模块,旅游路线分为四种情况:

  • 如果A地-B地往返都可以直达,那么查询两张机票(往返)
  • 如果A地-B地去程无法直达,需要中转,但是返程可以直达,那么查询三张机票(去程两张,返程一张)
  • 如果A地-B地去程可以直达,但是返程需要中转,那么查询三张机票(去程一张,返程两张)
  • 如果A地-B地往返都无法直达,那么查询四张机票(去程两张,返程两张)

在我重构前,代码差不多是这样的:

        int type = 1;
// 往返都可以直达
if (type == 1) {
// 查询出两张机票
return;
} // 去程无法直达,需要中转,但是返程可以直达
if (type == 2) {
// 查询出三张机票(去程两张,返程一张)
return;
}
// 去程可以直达,但是返程需要中转
if (type == 3) {
// 查询出三张机票(去程一张,返程两张)
return;
}
// 往返都无法直达
else{
// 查询出四张机票(去程两张,返程两张)
return;
}

当时我还是菜鸡(现在也是),也不懂什么设计模式,就是感觉代码都写在一个类中,实在是太长了,不够清爽,不管是哪种类型的线路,最终都是返回机票集合,只是处理逻辑不同,可以提取一个接口出来,再开四个类去实现此接口,最后定义一个Map,Key是Type,Value是接口(实现类),根据Type决定调用哪个实现类,就像下面的酱紫:

public class Ticket {
private String desc; public Ticket(String desc) {
this.desc = desc;
} public String getDesc() {
return desc;
} public void setDesc(String desc) {
this.desc = desc;
} @Override
public String toString() {
return "Ticket{" +
"desc='" + desc + '\'' +
'}';
}
}
public interface QueryTicketService {
List<Ticket> getTicketList();
}
public class QueryTicketAService implements QueryTicketService {
@Override
public List<Ticket> getTicketList() {
List<Ticket> list = new ArrayList<>();
list.add(new Ticket("去程机票"));
list.add(new Ticket("返程机票"));
return list;
}
}
public class QueryTicketBService implements QueryTicketService {
@Override
public List<Ticket> getTicketList() {
List<Ticket> list = new ArrayList<>();
list.add(new Ticket("去程第一张机票"));
list.add(new Ticket("去程第二张机票"));
list.add(new Ticket("返程机票"));
return list;
}
}
public class QueryTicketCService implements QueryTicketService {
@Override
public List<Ticket> getTicketList() {
List<Ticket> list = new ArrayList<>();
list.add(new Ticket("去程机票"));
list.add(new Ticket("返程第一张机票"));
list.add(new Ticket("返程第二张机票"));
return list;
}
}
public class QueryTicketDService implements QueryTicketService {
@Override
public List<Ticket> getTicketList() {
List<Ticket> list = new ArrayList<>();
list.add(new Ticket("去程第一张机票"));
list.add(new Ticket("去程第二张机票"));
list.add(new Ticket("返程第一张机票"));
list.add(new Ticket("返程第二张机票"));
return list;
}
}
public class Main {
static Map<Integer, QueryTicketService> map = new HashMap<>(); static {
map.put(1, new QueryTicketAService());
map.put(2, new QueryTicketBService());
map.put(3, new QueryTicketCService());
map.put(4, new QueryTicketDService());
} public static void main(String[] args) {
int type = 1;
System.out.println(map.get(type).getTicketList());
}
}

运行结果:

[Ticket{desc='去程机票'}, Ticket{desc='返程机票'}]

当初我也不知道什么设计模式,就是感觉这样写完,代码清爽多了,后来才知道这就是策略模式的雏形了。

GoF23种设计模式真正应用广泛的设计模式不多,但是策略模式绝对算其中之一了,你看,当初我都不懂这些,就写出了策略模式的雏形。

原始的策略模式

如果我们遇到类似于上面的需求,第一反应肯定是用if else语句或者switch语句,根据不同的情况执行不同的代码,这样做也没什么大问题,但是我们的项目会越来越复杂,这么做的缺陷就慢慢的显现了出来:如果现在线路新增了一个类型,需要中转两次,就又得加好几个判断的分支(去程中转一次,返程中转两次;去程中转两次,返程中转一次;去程直达,返程中转两次等等),想想就恐怖,这样分支会越来越多,代码会越来越长,越来越难以维护,所以策略模式出现了。

当一个逻辑中,有很多if else语句或者switch语句,而且它们需要解决的问题是一样的,就可以考虑策略模式。

最原始的策略模式有三个角色:

  • Strategy:抽象策略角色,对算法、策略的抽象,定义每个算法、策略所必需的方法,通常为接口。
  • ConcreteStrategy:具体策略角色,实现抽象策略角色,完成具体的算法、策略。
  • Context:上下文环境角色,保存了ConcreteStrategy,负责调用ConcreteStrategy。

而我上面的代码,就有了策略模式的味道,有了Strategy,也有了ConcreteStrategy,缺少的就是Context,如果用最原始的设计模式的写法来实现,是酱紫的:

public class Context {
static Map<Integer, QueryTicketStrategy> map = new HashMap<>(); static {
map.put(1, new QueryTicketAConcreteStrategy());
map.put(2, new QueryTicketBConcreteStrategy());
map.put(3, new QueryTicketCConcreteStrategy());
map.put(4, new QueryTicketDConcreteStrategy());
} public void getTicketList(int type) {
System.out.println(map.get(type).getTicketList());
}
}
public class Main {
public static void main(String[] args) {
Context context = new Context();
context.getTicketList(1);
}
}

运行结果:

[Ticket{desc='去程机票'}, Ticket{desc='返程机票'}]

在这里,我把类名重新定义了下,让人一眼就可以看出这里使用了策略模式,这也是阿里推荐的命名方法。

策略模式是不是很简单(我在学习设计模式的时候,甚至觉得它比单例、简单工厂还要简单),而且特别实用,下面我们来看看策略模式的UML图:

JDK中的策略模式

既然策略模式那么实用,那么在JDK中有策略模式的应用吗?当然有。JDK中定义的Comparator接口就是策略模式的一种实践了:

public class SortLengthComparator implements Comparator<String> {
@Override
public int compare(String o1, String o2) {
return (o1.length() - o2.length() > 0) ? 1 : -1;
}
}
public class Main {
public static void main(String[] args) {
List<String>list=new ArrayList<>();
list.add("hello");
list.add("world");
list.add("codebear");
list.add("balabala");
list.add("java");
list.sort(new SortLengthComparator());
System.out.println(list);
}
}

我定义了一个比较器,实现了Comparator接口,重写了compare方法,实现了以比较字符串长度来比较字符串的功能。

运行结果:

[java, world, hello, balabala, codebear]

Comparator接口就是Strategy,我定义的SortLengthComparator就是ConcreteStrategy。

Comparator结合Lambda,会产生怎样的火花

定义一个比较器,虽然不难,但是总觉得不够简洁,不够方便,需要新建一个类,所以现在越来越多的人使用Lambda来进行排序,就像下面的酱紫:

        List<String>list=new ArrayList<>();
list.add("hello");
list.add("world");
list.add("codebear");
list.add("balabala");
list.add("java");
List<String> newList = list.stream().sorted((a, b) -> (a.length() - b.length() > 0) ? 1 : -1).collect(Collectors.toList());
newList.forEach(System.out::println);

虽然底层还是用的Comparator,但是这样的写法清爽多了,如果比较的策略比较复杂,或者有多个地方都需要用到这个比较策略,还是用最原始的写法更好一些。

策略模式与Spring的碰撞

现在我们已经知道了什么是策略模式,如何使用策略模式,但是还有一个天大的问题,要知道,现在每个项目都在用Spring,如果你还是这么写的话:

public class Context {
static Map<Integer, QueryTicketStrategy> map = new HashMap<>(); static {
map.put(1, new QueryTicketAConcreteStrategy());
map.put(2, new QueryTicketBConcreteStrategy());
map.put(3, new QueryTicketCConcreteStrategy());
map.put(4, new QueryTicketDConcreteStrategy());
} public void getTicketList(int type) {
System.out.println(map.get(type).getTicketList());
}
}

就意味着实现类里面的依赖需要自己去维护,无法使用神奇的@Autowired注解,所以策略模式与Spring碰撞,策略模式必须发生一点改变,而这改变让策略模式变得更加简单,性能更好,也更加迷人。

写法1

@Service
public class QueryTicketAConcreteStrategy implements QueryTicketStrategy {
@Override
public List<Ticket> getTicketList() {
List<Ticket> list = new ArrayList<>();
list.add(new Ticket("去程机票"));
list.add(new Ticket("返程机票"));
return list;
}
}
@Service
public class QueryTicketDConcreteStrategy implements QueryTicketStrategy {
@Override
public List<Ticket> getTicketList() {
List<Ticket> list = new ArrayList<>();
list.add(new Ticket("去程第一张机票"));
list.add(new Ticket("去程第二张机票"));
list.add(new Ticket("返程第一张机票"));
list.add(new Ticket("返程第二张机票"));
return list;
}
}
@Service
public class Context { @Autowired
private QueryTicketStrategy queryTicketAConcreteStrategy; @Autowired
private QueryTicketStrategy queryTicketDConcreteStrategy; private static Map<Integer, QueryTicketStrategy> map = new HashMap<>(); @PostConstruct
public void init() {
map.put(1, queryTicketAConcreteStrategy);
map.put(4, queryTicketAConcreteStrategy);
} public void getTicketList(int type) {
System.out.println(map.get(type).getTicketList());
}
}
@SpringBootApplication
public class Main {
public static void main(String[] args) {
ConfigurableApplicationContext run = SpringApplication.run(Main.class, args);
run.getBean(Context.class).getTicketList(1);
}
}

运行结果:

[Ticket{desc='去程机票'}, Ticket{desc='返程机票'}]

原始的设计模式有一个缺点,不管是具体的策略实现类,还是上下文类,都不是单例模式,而我们的方法在大多数情况下是无状态的,所以改成单例模式是非常合适的,而结合了Spring,我们完全不需要手写单例模式,Spring就帮我们完成了。

写法2(自认为最优雅)

不管是原始的策略模式,还是Spring与策略模式结合的第一种写法,都没有完全符合开闭原则,如果有新的策略引入,必须修改上下文类,往map里面添加一组新的映射关系,而第二种写法完美的解决了这个问题,而且让策略模式变得非常优雅,下面直接放出代码:

@Service("1")
public class QueryTicketAConcreteStrategy implements QueryTicketStrategy {
@Override
public List<Ticket> getTicketList() {
List<Ticket> list = new ArrayList<>();
list.add(new Ticket("去程机票"));
list.add(new Ticket("返程机票"));
return list;
}
}
@Service("4")
public class QueryTicketDConcreteStrategy implements QueryTicketStrategy {
@Override
public List<Ticket> getTicketList() {
List<Ticket> list = new ArrayList<>();
list.add(new Ticket("去程第一张机票"));
list.add(new Ticket("去程第二张机票"));
list.add(new Ticket("返程第一张机票"));
list.add(new Ticket("返程第二张机票"));
return list;
}
}
@Service
public class Context { @Autowired
private Map<String, QueryTicketStrategy> map = new HashMap<>(); public void getTicketList(int type) {
String typeStr = String.valueOf(type);
System.out.println(map.get(typeStr).getTicketList());
}
}
@SpringBootApplication
public class Main {
public static void main(String[] args) {
ConfigurableApplicationContext run = SpringApplication.run(Main.class, args);
run.getBean(Context.class).getTicketList(1);
}
}

运行结果:

[Ticket{desc='去程机票'}, Ticket{desc='返程机票'}]

这就是Spring和神奇、迷人之处了,竟然可以自动注入map,key就是beanName,value就是接口(具体的实现类)。

用这种写法不但完成了天然的单例模式,而且真正的符合了开闭原则,引入新的策略,完全不需要修改任何一行旧代码,自认为这种写法是最优雅、最迷人的。

END

策略模式、策略模式与Spring的碰撞的更多相关文章

  1. 3.js模式-策略模式

    1. 策略模式 策略模式定义一系列的算法,把它们封装起来,并且可以互相替换. var strategies = { isNonEmpty: function(value,errMsg){ if(val ...

  2. 模板模式与策略模式/template模式与strategy模式/行为型模式

    模板模式 模版模式,又被称为模版方法模式,它可以将工作流程进行封装,并且对外提供了个性化的控制,但主流程外界不能修改,也就是说,模版方法模式中,将工作的主体架构规定好,具体类可以根据自己的需要,各自去 ...

  3. 命令模式 &amp; 策略模式 &amp; 模板方法

    一.策略模式 策略模式:封装易变化的算法,可互相替换. GoF<设计模式>中说道:定义一系列算法,把它们一个个封装起来,并且使它们可以相互替换.该模式使得算法可独立于它们的客户变化. 比如 ...

  4. Java设计模式(七)策略模式 模板模式

    (十三)策略模式 策略图案限定了多个封装算法,该算法可以相互替换包.法的客户.借用还有一位大神的样例. interface ICalculator{ public int calculate(Stri ...

  5. Springboot中实现策略模式+工厂模式

    策略模式和工厂模式相信大家都比较熟悉,但是大家有没有在springboot中实现策略和工厂模式? 具体策略模式和工厂模式的UML我就不给出来了,使用这个这两个模式主要是防止程序中出现大量的IF ELS ...

  6. 工厂模式&amp;策略模式。

    抽象.封装,具体事情做得越多,越容易犯错误.这每个做过具体工作的人都深有体会,相反,官做得越高,说出的话越抽象越笼统,犯错误可能性就越少.好象我们从编程序中也能悟出人生道理.(百度百科) 不断抽象封装 ...

  7. 简单工厂模式&amp;策略模式-简介与区别

    不得不说,这两种模式真的很像. 相似点:都用到了面向对象的继承.多态.抽象,都拥有相似的结构. 不同点:工厂模式仅提供具体的实例对象,怎么使用这个对象是client的自由,策略模式client可以通过 ...

  8. java之jvm学习笔记六-十二(实践写自己的安全管理器)(jar包的代码认证和签名) (实践对jar包的代码签名) (策略文件)(策略和保护域) (访问控制器) (访问控制器的栈校验机制) (jvm基本结构)

    java之jvm学习笔记六(实践写自己的安全管理器) 安全管理器SecurityManager里设计的内容实在是非常的庞大,它的核心方法就是checkPerssiom这个方法里又调用 AccessCo ...

  9. java设计模式——外观模式(门面模式)

    一. 定义与类型 定义:门面模式,提供一个统一的接口,用来访问子系统中的一群接口,门面模式定义了一个高层接口,让子系统更容易使用 类型:结构性 二. 使用场景 子系统越来越复杂,增加外观模式提供简单调 ...

  10. 组合模式/composite模式/对象结构型模式

    组合模式/composite模式/对象结构型 意图 将对象组合成树形结构以表示"整体--部分"的层次结构.Composite使得用户对单个对象和组合对象的使用具有一致性. 动机 C ...

随机推荐

  1. PHP 返回13位时间戳

    13位时间戳生成函数如下所示: private function getMillisecond() { list($t1, $t2) = explode(' ', microtime()); retu ...

  2. android 之 surfaceView和普通View的重绘使用

    !自定义控件式需要实现AttrbuteSet   可在xml文件中配置略过创建该对象 普通的View只能在主线程中绘制界面,适用于简单的被动绘制 SurfaceView则可以在新线程中绘制界面,不会阻 ...

  3. Memcached内存分配优化及使用问题

    前几天做了个Memcached的思考,并测试了一些数据,是关于如何提高Memcached内存使用率的问题.在启动memcached的时候可以加-f参数和-n参数.-f指定各slab里面chunk大小的 ...

  4. C#winform初试报表

    步骤1.新建一个窗口,拖一个ReportViewer控件上去,设置该控件的Dock为Fill. 步骤2.添加一个报表文件,如:Report1.rdlc,设置其中的参数,这里设置的参数和下面的代码里面的 ...

  5. Rails学习:create操作 局部模板

    学习Ruby on Rails实战真经 里面说rails4使用了strong parameters, 所以代码这么写:注意不是Event.new(params[:event])了,而是参数是函数返回值 ...

  6. Windows 之 CMD命令

    1. ipconfig 查看 Windows IP 配置 2. ping IP地址 查看远程IP是否通畅 2. ipconfig/flushdns 刷新和重置缓存 3. netsh winsock r ...

  7. classLoader (一)

    不说废话,上代码吧. 随便写一个类,他是由appclassLoader加载的 package classLoaderExample; class Bean { public void test() { ...

  8. IDEA debugger模式下启动慢

    很可能是因为代码里面有端点造成的. 点击如下图的重叠红点,找到对应端点点掉就可以了.

  9. 【angularjs】使用angularjs模拟淘宝首页-淘宝头条滚动效果

    <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <title> ...

  10. 为什么分布式一定要有redis?

    为什么分布式一定要有redis? 孤独烟 架构师小秘圈 昨天 作者:孤独烟 来自:http://rjzheng.cnblogs.com/ 1.为什么使用redis   分析:博主觉得在项目中使用red ...