1

説明させてください、私はあなたのコレクションを変更不可能にすることについて（信じられないほど）読んでいました、見てみましょうencapsulate collections、それは興味深いアイデアですが、実際の状況を想像することはできません。

誰かがそれの実用的なアプリケーションを説明できますか?

4

3 に答える 3

3

外部からリストを変更するとカプセル化が壊れてしまうため、オブジェクトのプライベート メンバーであるリストを返す場合に非常に便利です。

たとえばobj.getList().clear();、obj 内のリストをクリアします (getList() がプライベート メンバーを返すと仮定します) が、getList() が Collections.unmodifiableList に渡されたリストを返した場合、例外がスローされます。

于 2013-09-13T12:28:43.310 に答える
2

これには 2 つの主な利点があります。

  1. コーディング中に、サブクラスを作成せずに読み取り専用のコレクション クラスを作成できますが、すべてのタイプのコレクションで汎用の読み取り専用ラッパーを使用できます (再利用可能性)。
  2. 実行時に、コレクション全体を読み取り専用実装にコピーすることなく、既存のコレクションの読み取り専用ビューを作成できます (通常はコストがかかります)。

後者は、クラスのユーザーが独自の内部コレクションを変更できないようにする場合に役立ちます。

最近では、継承よりも構成を優先することも良い設計と見なされており、このパターンにうまく適合しています。

1の例:

class myComplicatedCollection<T> implements Collection<T> {
     // Code goes here

     // O no, I still have to deal with the read-only use-case.
     // Instead of duplicating almost all of my code or using inheritance I'll use this handy-dandy wrapper
     public Collection<T> readonlyVersion() {
          return Collections.unmodifiableCollection(this);
     }
}

2 の例:

class myClass {
     private Collection<T> theData;

     // Users need to access the data,
     // but we don't want them modifying the private data of this class
     public Collection<T> getTheData() {
         return Collections.unmodifiableCollection(theData);
     }
}
于 2013-09-13T12:24:22.833 に答える
2

リストを安全に公開したり、不変性を強制したりしたい場合はいつでも使用してください。

例えば：

// neither the reference nor the contents can change
private static final List<String> codes = Collections.unmodifiableList(Arrays.asList("a", "b", "c"));

このリストはクラス内で変更できず、安全に公開できます。

// the caller can't change the list returned
public static List<String> getCodes() {
    return codes;
}
于 2013-09-13T12:31:19.643 に答える