内部データ構造を常に完全にカプセル化する必要がありますか？

このクラスを考慮してください：

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThings(){
        return things;
    }

}

このクラスは、データを保存するために使用する配列を、関心のあるクライアントコードに公開します。

作業中のアプリでこれを行いました。sのChordProgressionシーケンスを格納するクラスがありましたChord（その他の処理も行います）。Chord[] getChords()コードの配列を返すメソッドがありました。データ構造を（配列からArrayListに）変更する必要がある場合、すべてのクライアントコードが破損しました。

これは私に考えさせられた-多分次のアプローチが優れている：

class ClassA{

    private Thing[] things; // stores data

    // stuff omitted

    public Thing[] getThing(int index){
        return things[index];
    }

    public int getDataSize(){
        return things.length;
    }

    public void setThing(int index, Thing thing){
        things[index] = thing;
    }

}

データ構造自体を公開する代わりに、データ構造によって提供されるすべての操作は、データ構造に委任するパブリックメソッドを使用して、データ構造を囲むクラスによって直接提供されるようになりました。

データ構造が変更された場合、これらのメソッドのみを変更する必要がありますが、変更後もすべてのクライアントコードは機能します。

配列よりも複雑なコレクションでは、内部データ構造にアクセスするためだけに3つ以上のメソッドを実装するために、囲むクラスが必要になる場合があることに注意してください。

このアプローチは一般的ですか？これについてどう思いますか？他にどんな欠点がありますか？内部データ構造に委任するために、少なくとも3つのパブリックメソッドを実装クラスで実装することは合理的ですか？

次のようなコード：

   public Thing[] getThings(){
        return things;
    }

あなたのアクセス方法は内部データ構造を直接返すだけで何もしないので、あまり意味がありません。同様に宣言Thing[] thingsすることもできますpublic。アクセス方法の背後にある考え方は、クライアントを内部の変更から隔離し、クライアントが実際のデータ構造を操作できないようにするインターフェイスを作成することです。ただし、インターフェイスで許可されている慎重な方法は除きます。すべてのクライアントコードが壊れたときに発見したように、アクセス方法はそれをしませんでした-それは無駄なコードです。多くのプログラマは、すべてをアクセスメソッドでカプセル化する必要があることをどこかで学んだため、そのようなコードを書く傾向があると思いますが、それは私が説明した理由によるものです。アクセス方法が何の目的にも役立たないときに「フォームに従う」ためだけに行うのは、単なるノイズです。

カプセル化の最も重要な目標のいくつかを達成する提案されたソリューションを絶対にお勧めします：クライアントにクラスの内部実装の詳細から隔離し、内部データ構造に触れることを許可しない堅牢で目立たないインターフェースを提供しますあなたが適切であると判断した方法で期待する-「必要最小限の特権の法則」。CLR、STL、VCLなどの人気のある大規模なOOPフレームワークを見ると、まさにその理由で、提案したパターンが広まっています。

あなたはいつもそうするべきですか？必ずしも。たとえば、基本的にメインワーカークラスのコンポーネントであり、「前向き」ではないヘルパークラスまたはフレンドクラスがある場合、それは必要ありません-それは多くの不必要なコードを追加することになる行き過ぎです。そして、その場合、私はアクセス方法をまったく使用しません-説明したように、それは無意味です。データ構造は、それを使用するメインクラスのみにスコープされる方法で宣言するだけです（ほとんどの言語はそれを行う方法をサポートしています）friend、またはメインワーカークラスなどと同じファイルで宣言します。

あなたの提案でわかるのは、コーディングするのにもっと手間がかかるという唯一の欠点です（そして今、あなたはコンシューマクラスを再コーディングする必要があります-しかし、とにかくそれをしなければならない/しなければなりませんでした）。 -あなたはそれを正しくする必要があり、時にはそれはより多くの作業を必要とします。

優れたプログラマーを優れたものにしていることの1つは、余分な仕事に価値があるときとそうでないときを知っていることです。長い目で見れば、今余分に投入することは将来大きな利益をもたらすでしょう-このプロジェクトでなければ、他のプロジェクトでも。ロボットで所定の形式に従うだけでなく、正しい方法でコーディングし、それについて頭を使うことを学びます。

配列よりも複雑なコレクションでは、内部データ構造にアクセスするためだけに3つ以上のメソッドを実装するために、囲むクラスが必要になる場合があることに注意してください。

包含クラスを通じてデータ構造全体を公開している場合、IMOでは、単により安全なインターフェース（「ラッパークラス」）を提供するためではない場合、そのクラスがまったくカプセル化されている理由を考える必要があります。あなたは、包含クラスがその目的のために存在しないと言っているので、おそらくあなたの設計について正しくない何かがあるでしょう。クラスをより慎重なモジュールに分割し、階層化することを検討してください。

クラスには明確で目立たない目的が1つあり、その機能をサポートするインターフェイスを提供する必要があります。一緒に属していないものを一緒にバンドルしようとしている可能性があります。それを行うと、変更を実装しなければならないたびに事態が破壊されます。クラスが小さく、慎重になればなるほど、物事を簡単に変更できるようになります。ThinkLEGO。

あなたは尋ねました：内部データ構造を常に完全にカプセル化すべきですか？

簡単な回答：はい、ほとんどの場合ですが、常にではありません。

ロングアンサー：クラスは次のカテゴリに従うと思います。

1. 単純なデータをカプセル化するクラス。例：2Dポイント。XおよびY座標を取得/設定する機能を提供するパブリック関数を作成するのは簡単ですが、内部データをあまり手間をかけずに簡単に隠すことができます。このようなクラスの場合、内部データ構造の詳細を公開する必要はありません。

2. コレクションをカプセル化するコンテナクラス。STLには古典的なコンテナクラスがあります。私もその中に考慮std::stringしstd::wstringます。彼らは抽象化に対処するための豊富なインタフェースを提供しますがstd::vector、std::stringとstd::wstringにも生データへのアクセスを取得する機能を提供します。私はそれらを貧弱に設計されたクラスと呼ぶのを急ぐことはないでしょう。これらのクラスが生データを公開する理由はわかりません。しかし、私の仕事では、パフォーマンス上の理由で数百万のメッシュノードとそれらのメッシュノード上のデータを処理する際に、生データを公開する必要があることがわかりました。

   クラスの内部構造を公開することに関する重要なことは、緑の信号を出す前に、長く真剣に考える必要があるということです。インターフェイスがプロジェクトの内部にある場合、将来変更するのは高価ですが、不可能ではありません。インターフェイスがプロジェクトの外部にある場合（他のアプリケーション開発者が使用するライブラリを開発しているときなど）、クライアントを失うことなくインターフェイスを変更することは不可能です。

3. 本質的にほとんど機能するクラス。例：std::istream、std::ostream、STLコンテナのイテレータ。これらのクラスの内部詳細を公開するのはまったくばかげています。

4. ハイブリッドクラス。これらは、いくつかのデータ構造をカプセル化するクラスですが、アルゴリズム機能も提供します。個人的には、これらはよく考えられていないデザインの結果だと思います。ただし、それらを見つけた場合は、ケースごとに内部データを公開することが理にかなっているかどうかを判断する必要があります。

結論として、クラスの内部データ構造を公開する必要があると判断したのは、パフォーマンスのボトルネックになったときだけです。

生データを直接返す代わりに、このようなものを試してください

class ClassA {
  private Things[] things;
  ...
  public Things[] asArray() { return things; }
  public List<Thing> asList() { ... }
  ...
}

そのため、基本的には、世界のあらゆる顔を表現するカスタムコレクションを提供しています。新しい実装では、

class ClassA {
  private List<Thing> things;
  ...
  public Things[] asArray() { return things.asArray(); }
  public List<Thing> asList() { return things; }
  ...
}

これで、適切なカプセル化が行われ、実装の詳細が隠され、後方互換性が提供されます（有料）。

これらのことにはインターフェースを使用する必要があります。Javaの配列はこれらのインターフェイスを実装していないため、あなたの場合は役に立ちませんが、今後はそれを行う必要があります。

class ClassA{

    public ClassA(){
        things = new ArrayList<Thing>();
    }

    private List<Thing> things; // stores data

    // stuff omitted

    public List<Thing> getThings(){
        return things;
    }

}

そうすれば、他のものに変更ArrayListすることができLinkedList、（擬似？）ランダムアクセスを持つすべてのJavaコレクション（配列以外）がおそらく実装するため、コードを壊すことはありませんList。

を使用することもできます。これはCollection、Listランダムアクセスなしでコレクションをサポートできるよりも少ないメソッドを提供するかIterable、ストリームをサポートすることもできますが、アクセスメソッドに関してはあまり提供しません...

これは、外部データ構造から内部データ構造を隠すために非常に一般的です。いつか特別にDTOで過剰になります。ドメインモデルにはこれをお勧めします。公開する必要がある場合は、不変のコピーを返します。これとともに、get、set、removeなどのこれらのメソッドを持つインターフェイスを作成することをお勧めします。