拡張検索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 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 dealOrderSourceCondition(String orderSource) {        
     List 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を追加し、伝達し、修正することです.目的地にも到達できます.しかし、――「不変」の原則を破壊した.可変原則の要求は、できるだけパラメータの修正を避けることです.このような行為を修正すると、目立たないバグを招きやすく、肝心なプロセスでこのことをすれば、故障を招く可能性があります.有線で教訓を得た.
どうしようかな?dealOrderSourceConditionのパラメータを変更することはできません.また、このメソッドの拡張検索条件を既存の拡張検索オブジェクトにマージします.
方法がある!拡張検索オブジェクトExtendSearchParamをマージします.これにより、ExtendSearchParamはマージ操作をサポートする必要があります.

public ExtendSearchParam merge(ExtendSearchParam extendSearchParam) {
    if (extendSearchParam != null && extendSearchParam.has()) {
      extendConditions.addAll(extendSearchParam.getUnmodifiedExtendSearch());
    }
    return extendSearchParam;
  }

これにより、dealOrderSourceConditionの戻り値をExtendSearchParamオブジェクトに変更することで、mergeメソッドを使用して拡張検索条件をマージできます.
Yeap ! 考えてみれば、マージ操作のほかに、どのような操作をサポートする必要がありますか?APIの設計は周到な考慮が必要で、1つの問題に出会って1つの支持を加えることができません!

ほじょほうしき

元のOrderSearchParamと連携して使用するには、次のような補助方法が必要です.

public boolean has() {
    return CollectionUtils.isNotEmpty(extendConditions);
  }

  public List getUnmodifiedExtendSearch() {
    return Collections.unmodifiableList(extendConditions);
  }

小結

この論文では、拡張検索APIの最適化プロセスについて説明します.良いAPI設計は、ビジネス側の使用体験を向上させ、メンテナンスコストを削減します.優雅なAPIを設計するには、工場方法、リロード方法、常用操作など、いくつかのテクニックを身につける必要があります.
仕事の中から最適化が必要なところを絶えず発見し、方法とテクニックを身につけて解決することも、スキルを向上させる方法です.