一个扩展搜索API的优化过程
概述
API 是一个服务的门面，就像衣装是人的形象一样。
优雅的 API 设计，能让业务方使用起来倍儿爽，提升开发效率，降低维护成本；糟糕的 API 设计，则让业务方遭心，陷入混沌。
本文将展示一个扩展搜索 API 的优化过程，从中也可以学到一些东西。
现状
找一个上游工程的扩展搜索代码如下：
extendKeywords.add((EsCondition) ConditionFactory.in("order_tags", Arrays.asList("IS_XXX_ORDER")));
extendKeywords.add(new EsCondition("goods_title", Op.match, new Match(goodsTitle, "100%")));
啊啊，真是丑死了 ！ 为什么呢 ？
- 强制类型转换。 让业务方写强制类型转换，简直是让业务方来遭罪的 ！ 这 API 设计简直了 ！
- 暴漏底层细节。 让业务方 new EsCondition ，不仅是暴漏底层细节，还很难看！
- 不方便的传值。 为了传一个 in 的数值，需要写个 Arrays.asList(e) ！
- 遍布的 EsCondition 。 由于 API 设计的很裸，导致上游工程到处弥漫着 EsCondition 的烟雾。
emmm... 其实是我设计的 API 造的孽 ！ 解铃还须系铃人。
优化过程
工厂方法
这种硬的 new EsConditon ，完全可以通过工厂方法和方法重载来消除。此外，为了收拢扩展搜索条件的构建，可以构建一个专门的 ExtendSearchParam 。
public class ExtendSearchParam implements Serializable {
private static final long serialVersionUID = 2824767430430079287L;
private List<EsCondition> extendConditions = new ArrayList<>();
public ExtendSearchParam addEq(String field, Object value) {
extendConditions.add(new EsCondition(field, Op.eq, value));
return this;
}
public ExtendSearchParam addIn(String field, Object... list) {
extendConditions.add(new EsCondition(field, Op.in, list));
return this;
}
public ExtendSearchParam addRange(String field, long gte, long lte) {
extendConditions.add(new EsCondition(field, Op.range, new Range(gte, lte)));
return this;
}
public ExtendSearchParam addMatch(String field, String query) {
extendConditions.add(new EsCondition(field, Op.match, new Match(query, "100%")));
return this;
}
public ExtendSearchParam addMatch(String field, String query, String match) {
extendConditions.add(new EsCondition(field, Op.match, new Match(query, match)));
return this;
}
}
这里借鉴了 Builder 模式，能够链式地构建扩展搜索条件。这样，业务方就可以舒心地写上：
extendSearchParam.addIn(ORDER_TAGS, "IS_XXX_ORDER").addMatch("goods_title", goodsTitle);
没有了类型强制转换，没有了暴漏底层细节，没有了不方便的传值，还可以一直 add 下去， 世界多美好 ！
拦路虎
很快，就遇到了拦路虎：
private List<EsCondition> dealOrderSourceCondition(String orderSource) {
List<EsCondition> result = new ArrayList();
result.add(new EsCondition(TYPE_ENTRANCE, Op.eq, "wsc"));
result.add(new EsCondition(TYPE_PLATFORM, Op.eq, "wx"));
return result;
}
emmm , 写这个方法的小伙伴也是好意，封装一个方法来构建订单来源扩展条件也是好意。不过这给API 重构带来了一点点小小的障碍。
怎么重写这一段呢 ？ 第一想到的是，在 dealOrderSourceCondition 的方法里额外增加一个参数 ExtendSearchParam ，传进去，修改它。也能达到目地。但是，—— 破坏了“不可变”原则。 不可变原则要求，尽可能避免修改入参。修改入参这种行为，很容易导致不起眼的 BUG ，如果在关键流程中做这个事情，有可能导致故障。有线上教训的。
怎么办呢 ？ 又不能修改 dealOrderSourceCondition 的入参，又要把这个方法的扩展搜索条件合并到已有的扩展搜索对象中。
有一种办法 ！ 合并扩展搜索对象 ExtendSearchParam 。 这样，ExtendSearchParam 需要支持一个合并操作：
public ExtendSearchParam merge(ExtendSearchParam extendSearchParam) {
if (extendSearchParam != null && extendSearchParam.has()) {
extendConditions.addAll(extendSearchParam.getUnmodifiedExtendSearch());
}
return extendSearchParam;
}
这样，将 dealOrderSourceCondition 的返回值改为 ExtendSearchParam 对象，就能使用 merge 方法来合并扩展搜索条件了。
Yeap ! 想一想，除了 合并操作，还需要支持哪些操作呢 ？API 设计需要考虑周全，可不能遇到一个问题加一个支持啊 ！
辅助方法
为了与原来的 OrderSearchParam 联合使用， 需要加一些辅助方法，比如：
public boolean has() {
return CollectionUtils.isNotEmpty(extendConditions);
}
public List<EsCondition> getUnmodifiedExtendSearch() {
return Collections.unmodifiableList(extendConditions);
}
小结
本文讲解了一个扩展搜索 API 的优化过程。好的 API 设计能提升业务方的使用体验，降低维护成本。设计优雅的 API ，需要掌握一些技巧：工厂方法、重载方法、常用操作等。
从工作中不断发现需要优化的地方，掌握方法和技巧去解决， 也是一种提升技能的方式。
