サンプルの 1 つから派生した MonoTouch コードに取り組んでおり (これは MonoTouch 固有の質問ではありません)、サンプル コードは別のクラス内でプライベート クラスを宣言しています。私はプライベート クラスが c# であまり使用されているのを見たことがありません。別のクラス内でのみ参照されるクラスをプライベートとして宣言する方法はわかりますが、これは価値以上の悲しみを引き起こすのではないでしょうか? これは多くの SOLID 原則を破っていませんか?
現時点では、プライベート クラスの定義のために、ソースをナビゲートしようとするだけで混乱を招きます。これは、部分クラスにプライベート クラスを含めるように宣言し、それらを個別のファイルに分割することで多少軽減できると思いますが、これは本当に良いアプローチですか?
通常、ネストされた型 (列挙を含むクラスまたは構造体のいずれか) は、コンテキストなしでは意味を持たない、ある種のコンテキスト データおよび/または動作に使用されます。
たとえば、外部コードからその API へのアクセスを提供したくない場合、または周囲のクラスにのみ役立つ機能を提供するある種のヘルパー データ コンテナーを使用している場合に、一部の相互運用 API 用にネストされた型を作成できます。
そのため、これらの型を作成しても、internal他の開発者に混乱を招く可能性があります (特に、1 つのプロジェクトが複数の人によって編集されている場合)。
ここで SOLID がどのように壊れているのかわかりません-型をネストすることは、型のスコープを制限するだけです。周囲のクラスの機能を拡張するものではありません。
私は、API が「このインターフェースの実装を要求したときに実装して提供する必要がある」と言う状況でプライベート クラスを使用しましたが、API の使用以外にそのクラスの使用または消費者はありません。インターフェース。
この状況では、インターフェースはパブリックまたは機能横断的なアクセスを提供するため、実装にアクセスする必要はありません。
なぜSRPが壊れたのですか？クラス内でのみアクセスされる責任をネストされたクラスに分離します。
他のほとんどの原則は、プライベートメンバーまたはプライベートネストされたクラスには適用されません。
よくわかりませんが、ネストされたクラスによって単一の責任が壊れる可能性があると思います。これは、クラスを変更する理由が増える可能性があるためです。Single Resposibilty の定義はあまり明確ではありません... とにかく、ms は .net でネストされたクラスも使用していると思います。そのため、カプセル化に関して c# にはいくつかの機能が欠けている可能性があります。ネストされたクラスは、ネストされたクラスを実行せずにアナライザーを作成することで修正できると思います。ネストされたクラスは、ラッピング クラスのプライベート メンバーにアクセスするためによく使用されます。