Google GuiceのBest Practicesを訳してみた - Moduleでは条件分岐を避けよ

Moduleでは条件分岐を避けよ
Moduleに変化する部品をもたせることと、異なった環境で異なった動作をするように定義するのは推奨されない。

public class FooModule {
  private final String fooServer;

  public FooModule() {
    this(null);
  }

  public FooModule(@Nullable String fooServer) {
    this.fooServer = fooServer;
  }

  @Override protected void configure() {
    if (fooServer != null) {
      bind(String.class).annotatedWith(named("fooServer")).toInstance(fooServer);
      bind(FooService.class).to(RemoteFooService.class);
    } else {
      bind(FooService.class).to(InMemoryFooService.class);
    }
  }
}

条件分岐自身にはそれほど問題はない。しかし、設定がテストされていない時に問題は現れる。この例では、InMemoryFooServiceは開発環境で使用され、RemoteFooServiceは本番環境で使用される。しかし、この特定の状況をテストしていないと、RemoteFooServiceが統合されたアプリケーションと動作するかは保証できない。

このことからわかるのは、アプリケーションの設定項目は最小限にすべきだということだ。開発環境と本番環境を別々のModuleへ分割すると、本番コードの全てがテストされているのを証明するのはより容易になる。この例では、FooModuleをRemoteFooModuleとInMemoryFooModuleへ分割する。これはまた、製品版のクラスがテストコードに依存しなくなる効果もある。

参照
Avoid conditional logic in modules