ImmutableMapまたはMapを返す方が良いですか？

Mapを返すメソッドを書いているとしましょう。例えば：

public Map<String, Integer> foo() {
  return new HashMap<String, Integer>();
}

しばらく考えた結果、このマップが作成された後で変更する理由はないと判断しました。したがって、私はImmutableMapを返したいと思います。

public Map<String, Integer> foo() {
  return ImmutableMap.of();
}

戻り値の型を汎用のMapのままにするか、ImmutableMapを返すように指定する必要がありますか？

一方で、これがまさにインターフェースが作成された理由です。実装の詳細を非表示にします。
一方、このままにしておくと、他の開発者はこのオブジェクトが不変であるという事実を見逃す可能性があります。したがって、私は不変オブジェクトの主要な目標を達成しません。変更可能なオブジェクトの数を最小限に抑えてコードをより明確にするため。最悪の場合でも、しばらくすると、誰かがこのオブジェクトを変更しようとする可能性があり、これによりランタイムエラーが発生します（コンパイラーは警告しません）。

• 公開されているAPIを作成していて、その不変性が設計の重要な側面である場合、返されるマップが不変であることをメソッドの名前が明確に示すことによって、または具体的なタイプを返すことによって、それを明確にします地図。私の意見では、javadocで言及するだけでは十分ではありません。

  あなたは明らかにGuava実装を使用しているので、私はドキュメントを調べましたが、それは抽象クラスなので、実際の具象型に少し柔軟性を与えます。

• 内部ツール/ライブラリを作成している場合は、単純なを返すだけで十分Mapです。人々は彼らが呼んでいるコードの内部について知っているか、少なくともそれに簡単にアクセスできるでしょう。

私の結論は、露骨な表現は良いことであり、物事を偶然に任せないことです。

ImmutableMap戻り値の型として持っている必要があります。Map実装によってサポートされていないメソッドが含まれImmutableMap（例えばput）とマークされている@deprecated中をImmutableMap。

非推奨のメソッドを使用するとコンパイラの警告が表示され、ほとんどのIDEは非推奨のメソッドを使用しようとすると警告します。

この高度な警告は、何かが間違っているという最初のヒントとして、実行時の例外よりも望ましいです。

一方、このままにしておくと、他の開発者はこのオブジェクトが不変であるという事実を見落とす可能性があります。

javadocsでそれを言及する必要があります。開発者はそれらを読んでいますね。

したがって、私は不変オブジェクトの主要な目標を達成しません。変更可能なオブジェクトの数を最小限に抑えてコードをより明確にするため。最悪の場合でも、しばらくすると、誰かがこのオブジェクトを変更しようとする可能性があり、これによりランタイムエラーが発生します（コンパイラーは警告しません）。

テストされていないコードを公開している開発者はいません。そしてそれをテストすると、理由だけでなく、不変のマップに書き込もうとしたファイルと行も確認できる例外がスローされます。

ただし、Map不変になるのはそれ自体だけであり、それが含むオブジェクトではありません。

このままにしておくと、他の開発者がこのオブジェクトが不変であるという事実を見逃す可能性があります

それは事実ですが、他の開発者はコードをテストして、それがカバーされていることを確認する必要があります。

それでも、これを解決するための2つのオプションがあります。

• Javadocを使用する

  @return a immutable map

• 説明的なメソッド名を選択した

  public Map<String, Integer> getImmutableMap()
  public Map<String, Integer> getUnmodifiableEntries()

  具体的な使用例については、メソッドに名前を付けることもできます。例えば

  public Map<String, Integer> getUnmodifiableCountByWords()

他に何ができますか？！

あなたは返すことができます

• 写す

  private Map<String, Integer> myMap;
  
  public Map<String, Integer> foo() {
    return new HashMap<String, Integer>(myMap);
  }

  このアプローチは、多くのクライアントがマップを変更することが予想され、マップに含まれるエントリが少ない場合にのみ使用してください。

• CopyOnWriteMap

  copy on writeコレクションは通常、
  同時実行性を処理する必要がある場合に使用されます。ただし、CopyOnWriteMapは変更操作（追加、削除など）で内部データ構造のコピーを作成するため、この概念は状況にも役立ちます。

  この場合、変更操作を除いて、すべてのメソッド呼び出しを基になるマップに委譲する、マップの薄いラッパーが必要です。変更操作が呼び出されると、基になるマップのコピーが作成され、それ以降の呼び出しはすべてこのコピーに委任されます。

  このアプローチは、一部のクライアントがマップを変更することが予想される場合に使用する必要があります。

  悲しいことに、javaにはそのようなはありませんCopyOnWriteMap。しかし、サードパーティを見つけたり、自分で実装したりすることもできます。

最後に、マップ内の要素がまだ変更可能である可能性があることを覚えておく必要があります。

間違いなくImmutableMapを返します。

• メソッドシグネチャ（戻り値の型を含む）は自己文書化する必要があります。コメントはカスタマーサービスのようなものです。クライアントがそれらに依存する必要がある場合、主要製品に欠陥があります。
• 何かがインターフェースであるかクラスであるかは、それを拡張または実装するときにのみ関係します。インスタンス（オブジェクト）が与えられると、99％の時間、クライアントコードは何かがインターフェイスであるかクラスであるかを知らないか気にしません。私は最初、ImmutableMapがインターフェースであると想定しました。リンクをクリックして初めて、それがクラスであることがわかりました。

クラスによって異なります。Guava ImmutableMapは、変更可能なクラスへの不変のビューになることを意図していません。クラスが不変でありImmutableMap、基本的にである構造を持っている場合は、戻り値の型を作成しImmutableMapます。ただし、クラスが変更可能な場合は変更しないでください。これがあれば：

public ImmutableMap<String, Integer> foo() {
    return ImmutableMap.copyOf(internalMap);
}

グアバは毎回マップをコピーします。それは遅いです。しかし、internalMapすでにだったImmutableMap場合、それはまったく問題ありません。

クラスをImmutableMapreturnに制限しない場合は、代わりに次のCollections.unmodifiableMapように返すことができます。

public Map<String, Integer> foo() {
    return Collections.unmodifiableMap(internalMap);
}

これは地図への不変のビューであることに注意してください。internalMap変更された場合、キャッシュされたのコピーも変更されますCollections.unmodifiableMap(internalMap)。ただし、ゲッターにはまだ好んで使用しています。

これは正確な質問には答えませんが、マップを返す必要があるかどうかを検討する価値はあります。マップが不変の場合、提供される主要なメソッドはget（key）に基づいています。

public Integer fooOf(String key) {
    return map.get(key);
}

これにより、APIが大幅に強化されます。マップが実際に必要な場合は、エントリのストリームを提供することにより、APIのクライアントに任せることができます。

public Stream<Map.Entry<String, Integer>> foos() {
    map.entrySet().stream()
}

次に、クライアントは、必要に応じて独自の不変マップまたは可変マップを作成するか、独自のマップにエントリを追加できます。クライアントが値が存在するかどうかを知る必要がある場合は、代わりにオプションを返すことができます：

public Optional<Integer> fooOf(String key) {
    return Optional.ofNullable(map.get(key));
}

不変マップはマップの一種です。したがって、戻り値の型のMapを残しても問題ありません。

ユーザーが返されたオブジェクトを変更しないようにするために、メソッドのドキュメントでは、返されたオブジェクトの特性を説明できます。

これは間違いなく意見の問題ですが、ここでのより良いアイデアは、マップクラスのインターフェイスを使用することです。このインターフェイスは不変であると明示的に言う必要はありませんが、インターフェイスで親クラスのセッターメソッドを公開しない場合、メッセージは同じになります。

次の記事をご覧ください。

アンディ・ギブソン