大家好，阿清最近遇到这样一个活儿：组装sql语句。
以查询语句举例：
依据传来的各种参数，包括列名，表名，查询条件等，阿清将这些参数拼装成一条完整的sql查询语句。
阿清心想，我是不是得依据sql的关键字来写一些方法呢？
比如，依据select关键字拼一段sql;
依据from关键字拼一段sql (且这段sql还要在多表的情况下，还得拼出查询条件)；
再依据where关键字拼一段sql，且同时，也有可能没有查询条件，这个时候就不需要拼where语句了。
一直以来，阿清写代码都是想到哪写到哪，今天决定踏出舒适圈，尝试使用设计模式~
经过一番查阅，阿清感觉可以使用建造者模式 。
建造者模式
建造者模式使用一些简单的对象构建一个复杂的对象。
即当需要构建一个复杂对象时，我们往往需要先构建一些简单的对象，再将这些对象进行组合，便得到了我们需要的复杂对象。
回到我们这个任务，一个完整的查询sql，本来就有三个关键字，分别是：select、from、where。
以这三个关键字，划分出三个部分，先创建好这三个部分，再拼成一个查询sql，这个流程正好符合建造者模式。
于是，阿清设计了一个粗略的类结构图：
阿清依据建造者模式构建了两个核心类。
第一，阿清构造一个抽象类SqlPart，它用来拼接相应关键字对应的部分sql。
其中它有一个私用属性List，用来接收参数，并有一个assemble方法来将这些参数拼装起来，组成相应部分的sql。
接着，阿清设计了三个子类分别对应以select、from、where划分出来的三个部分，它们都将继承SqlPart这个类, 用来构建sql的不同部分。
第二，阿清构造了一个QuerySqlBuilder，它用来将各个部分的sql拼装起来，形成一个完整查询sql。
它拥有一个私有属性LIst<SqlPart> sqlParts , 以及三个方法。
第一个方法initialSqlPart将初始化sqlParts，它会调用第二个方法。
第二个方法addSqlPart，它将往sqlParts塞入不同的SqlPart对象，包括SelectSqlPart、FromSqlPart、WhereSqlPart，当然每种类型只能塞入一次。
第三个方法out负责输出完整的查询sql语句。
最后，阿清想对几个函数的签名做一些解释。
initialSqlPart传入的是一个Map，且没有声明具体的泛型。首先，key是一个标识，表示这个键值对传入的是哪个部分的参数。例如可以用String作为key，当key为select时，则对应select部分，为from时，则对应from部分。
那么value呢？
对于，每个部分则都不一样。
当参数对应select部分时， 此时Value是一个List<String>, 它只用储存好列名即可。
当参数对应from部分时，此时Value是一个List<Info>,其中Info包含两个属性，一个是表名，一个是连接字段。
当参数对应where部分时，此时Value是一个Map<String, String>, 其中key是列名，value则是具体对应的值，以此拼接成查询条件。
此时，我突然想到一个问题，针对from部分，连接的条件是inner join ，还是 left join ，亦或是 right join呢?
那么，针对这一点，应该还需要再来设计连接方式的标识。
总结
啊~，说了这么多，阿清感觉这次的设计只是带出了一个框架，关于这些细节，阿清还需要继续琢磨。
也许从FromSqlPart中还需要继续设计新的类来满足不同的连接方式。
今天，阿清在这里抛砖引玉，记录一下自己的想法，给自己的设计模式使用之旅开一个头~
让我们一起尝试，一起修炼设计模式！
关注六只栗子，面试不迷路~
作者 阿清
编辑 一口栗子
原文始发于微信公众号（六只栗子）：我下定决心，使用一次设计模式
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/88231.html
