日あたりの1つのデザインパターンファーストポスト

なぜですか.
よく設計されたパターンは本当に私の強いポイントではなく、自然に私たちがしなければならない取得します.それは完璧ではないので、あなたの批判は歓迎です.

日の問題?
最近、私は別の開発者仕事を見る機会を得ました.開発者は、特定のAPIに協議するアプリケーションを書いていた.APIは最近改訂されました、そして、上部管理はアプリケーションが配備構成に従い両方のバージョンに話すことができたことを望みました.

どのように、開発者は問題を解決しましたか?
開発者はif アプリケーションの各ルートの下のコントロール構造は、APIの3つのバージョンの適切なコードを実行する.

アプローチによる知覚問題?

非常に長く肥大した関数

コードを理解しにくい

各ルートの下に抽象化のあまりにも多くのレベル

私の考え?
私の観点から、問題はAPIバージョンを選ぶこととそれから適切なAPIインスタンスをつくることを含みます.それはクラスのインスタンス化とオブジェクトの作成の下で落ちる可能性があるようです.

どうやってそれをやったのだろう?

APIを定義するインターフェイスを作成する

任意のバージョンを実装

バージョンを指定した適切なインスタンスを作成するファクトリを作成する

ERMでは、コードは以下のようになります(エラーがあるかもしれません.

インタフェース:

  public interface API
  {
    public void doSomething();
    public void doOneMoreThing();
  }

APIインスタンス

  public class ApiV1 implements API
  {
    public void doSomething()
    {
      // doing something
    }

    public void doOneMoreThing()
    {
      // doing one more thing
    }
  }

  public class ApiV2 implements API
  {
    public void doSomething()
    {
      // doing something but slightly differently
    }

    public void doOneMoreThing()
    {
      // doing one more thing but slightly differently
    }
  }

工場

  public class APIFactory
  {
    private Map<String, API> apiMap =  Map.ofEntries(entry("v1", ApiV1),
                                                     entry("v2", ApiV2));

    public API getApiIstance (string version)
    {
      if (!this.apiMap.containsKey(version)) {
        throw new IllegalArgumentException("Passed API version does not exist.");
      }
      return this.apiMap.get(version)();
    }
  }

使用法:

  // assuming there is a config somewhere
  API apiv1 = APIFactory().getApiInstance(config.apiVersion);

まとめ
そうerm、はい.完璧ではなく、おそらく正しい方向へのステップ.