今天你的leader兴致冲冲地找到你，希望你能够帮他一个小忙。他如今急着要去开会。要帮什么忙呢？你非常好奇。

他对你说。当前你们项目的数据库中有一张用户信息表。里面存放了非常用户的数据。如今须要完毕一个选择性查询用户信息的功能。

他说会传递给你一个包括很多username的数组。你须要依据这些username把他们对应的数据都给查出来。

这个功能非常easy的嘛。你爽快地答应了。

因为你们项目使用的是MySQL数据库，你非常快地写出了例如以下代码：

这里依据传入的username数组拼装了SQL语句，然后去数据库中查找对应的行。为了方面调试。你还将拼装好的SQL语句打印了出来。

然后，你写了例如以下代码来測试这种方法：

如今执行一下測试代码，你发现程序出错了。于是你立马去检查了一下打印的SQL语句，果然发现了问题。

拼装出来的SQL语句在最后多加了一个 or keyword。由于for循环运行到最后一条数据时不应该再加上or，但是代码非常笨地给最后一条数据也加了orkeyword。导致SQL语句语法出错了。

这可怎么办呢？

有了。你灵光一闪，想出了一个解决的方法。

等SQL语句拼装完毕后，把最后一个or删除掉不就好了么。于是你将代码改成例如以下所看到的：

使用StringBuilder的delete方法，把最后多余的一个or删除掉了，这样再执行測试代码。一切就正常了，打印的SQL语句例如以下所看到的：

好了，完工！你自信满满。

你的leader开完会后，过来看了下你的成果。整体来说。他还挺惬意。但对于你使用的SQL语句拼装算法，他总是感觉有些不正确劲，但是又说不上哪里不好。

于是他告诉了你还有一种拼装SQL语句的算法。让你增加到代码中，但是之前的那种算法也不要删除。先保留着再说，然后他又非常忙似的跑开了。

于是，你把他刚刚教你的算法加了进去，代码例如以下所看到的：

能够看到，你leader教你的拼装算法。使用了一个布尔变量来控制是否须要加个or这个keyword。第一次运行for循环的时候由于该布尔值为false，所以不会加上or，在循环的最后将布尔值赋值为true，这样以后循环每次都会在头部加上一个orkeyword。由于使用了头部加入or的方法。所以不用再操心SQL语句的尾部会多出一个or来。然后你为了将两个算法都保留，在findUserInfo方法上加了一个參数，strategy值为1表示使用第一种算法。strategy值为2表示使用另外一种算法。

这样測试代码也须要改成例如以下方式：

这里你通过參数指明了使用另外一种算法来拼装SQL语句。打印的结果和使用第一种算法是全然同样的。

你立马把你的leader从百忙之中拖了过来。让他检验一下你当前的成果，但是他还是一如既往的挑剔。

“你这样写的话，findUserInfo这种方法的逻辑就太复杂了，很不利于阅读，也不利于将来的扩展，假设我还有第三第四种算法想加进去，这种方法还能看吗？”  你的leader指点你，遇到这样的情况，就要使用策略模式来解决，策略模式的核心思想就是把算法提取出来放到一个独立的对象中。

为了指点你。他不顾自己的百忙，開始教你怎样使用策略模式进行优化。

首先定义一个策略接口：

然后定义两个子类都实现了上述接口，并将两种拼装SQL语句的算法分别增加两个子类中：

然后把QueryUtil中findUserInfo方法的第二个參数改成Strategy对象，这样仅仅须要调用Strategy的getSQL方法就能够获得拼装好的SQL语句，代码例如以下所看到的：

最后，測试代码在调用findUserInfo方法时。仅仅须要显示地指明须要使用哪一个策略对象就能够了：

打印出的SQL语句丝毫不出预料。例如以下所看到的：

使用策略模式改动之后，代码的可读性和扩展性都有了非常大的提高。即使以后还须要加入新的算法。你也是手到擒来了！

策略：它定义了算法家庭，分别封装起来。让它们之间能够互相替换。此模式让算法的变化。不会影响到使用算法的客户。