ネストされたクラス：便利なツールまたはカプセル化違反？

だから、私はこれらを使用すべきかどうかについて、まだフェンスの上にいます。

カプセル化の極端な違反を感じますが、コードの柔軟性を高めながら、ある程度のカプセル化を達成できることがわかりました。

以前のJava / Swingプロジェクトでは、ネストされたクラスをある程度使用していましたが、C＃で他のプロジェクトに移動したため、使用を避けています。

ネストされたクラスについてどう思いますか？

簡単に言えば、ネストされたクラスはカプセル化に違反せず、一般に、言語機能はプログラミングの原則に違反しません。プログラマーはプログラミングの原則に違反します。

面白いことに、ネストされたクラスはカプセル化を増やすと主張されています：

カプセル化の強化-2つの最上位クラス、AとBを検討します。Bは、そうでなければプライベートと宣言されるAのメンバーにアクセスする必要があります。クラスA内でクラスBを非表示にすることにより、Aのメンバーはプライベートと宣言され、Bはそれらにアクセスできます。さらに、B自体を外界から隠すことができます。

その中にはいくつかの真実があります。

通常、BはSRPをA に適用した結果です。ただし、B自体は潜在的に多くの原則に違反します。特に、Aのプライベートメンバーをいじるだけである場合は、D

隠しクラスは役に立つと思います。しかし、誤用の可能性がたくさんあります。

ネストされたクラスを常に使用します。多くの場合、ビジネスソフトウェア/プロセスにはネストされたビジネスオブジェクトがあります。OrderItemのネストされたコレクションを持つOrderオブジェクトの例を見てきました。

一番下の行は、コードの読み取り/書き込みを簡単にし、Orderクラスが必要で、OrderItemsを知る必要がない場合はめったにありません。

個人的には、さまざまな（通常は好ましくない）方法でデザインを結合するため、避けるべきだと思います。

ただし、プロジェクトにスコープが設定され、クラス（特定のクラスのデータ構造をトラバースするために使用されるNodeクラスや何らかのオブジェクトなど）をカプセル化する場合、害はありません。

実際、特定の種類のプロジェクトでは、コード（および推論）が読みやすく/理解しやすくなると思います。ただし、拡張性を念頭に置いたほとんどのプロジェクトでは、それらを分離することで問題が発生することはめったにないので、悪い考えだと思いますが、それらを一緒にすると、将来それらを切り離すことを余儀なくされる可能性があります（無駄な時間です）。

（C＃の場合）クラスの目的が何であるかは正確に依存しますが、通常はそれらを避けます。

どんな種類のドメインモデルクラスにもそれらを使用することはありません。

以前は外部クラスでプライベートなデータを構造化するためにそれらを使用していましたが、これらはほとんど常にプロジェクトのライフサイクルの後半に外部で必要になることがわかったので、通常はこれを気にしません。

今私がそれらを使用するのは、別の小さなクラスを使用すると特定のクラスを簡単に実装できる奇妙な小さなコーディングのトリック、または実際には単なるイベント通知パターンであるインターフェイスの実装（内部クラスがインターフェイスを実装し、外部クラスを制御します）。