私は他の誰もが知らないことを知っていると言っているわけではありませんが、ネストされたクラスを使用してますます多くのデザインを解決してきました。設計メカニズム。
これは私に質問を導きます：彼らが私を噛むように戻ってきたときに私が発見する理由のために、私は本質的に悪い道を進んでいますか、またはネストされたクラスはおそらく過小評価されているものですか？
次に、私がそれらを使用した2つの例を示します。https：//gist.github.com/3975581-1つ目は、密接に関連する階層的なものを一緒に保つのに役立ち、2つ目は、保護されたメンバーへのアクセス権をワーカーに与えました...
回答:
私はこれを「めったに使用されない設計メカニズム」とは呼びません。少なくとも、普遍的ではありません。一部の寄稿者がネストされたクラスの使用を嫌うショップもありますが、これは完全な機能ではありません。
アセンブリの可視性を備えたクラスの存在とラムダの導入により、ネストされたクラス*の必要性が大幅に減少しましたが、それらは依然として有効な設計上の選択です。名前空間内の内部クラスと一部重複がありますが、ネストされたクラス機能は、クラスを完全に別のクラス内に隠すことができるという点で独特です。
* C＃で利用可能な他の代替手段がJavaにはないため、Javaでの同様の機能の使用ははるかに高くなります。
少しの間、別のクラス内にクラスを作成していることを考えてください。クラスはプログラムの他の場所では使用されません。他の場所で使用している場合は、他のクラスと同じように、通常のパブリッククラスにするからです。
したがって、OOPを優れたものにする（再利用可能な）はずのものがここにはありません。さらに、親クラス内の通常のメソッドやプライベートメンバーでは達成できなかった、ネストされたクラスで達成できることは何ですか？
ネストされたクラスを利用する便利なソフトウェアパターンについては、こちらをご覧ください。
am I going down an inherintly bad path
2番目の例（workerサブクラス）では間違いなくそうです。各サブクラスをスーパークラスの特定の状態にマップしました。したがって、スーパークラスに状態を追加するたびに、3つの場所で状態を変更する必要があります（スーパークラスに状態を追加し、新しいサブクラスを追加し、派生クラスのコンストラクターを変更してサブクラスをリストに追加します） ）。
ネストされたクラスを使用してプライベートメンバーにアクセスすることは有効であるように見えますが（私が個人的に行ったことはありません）、ここでは特定のケースが機能しません。
ボディパーツ例も。ネストされたクラスはすべてパブリックであるため、名前空間を除いて実際には多くのことを行っていません。これらのクラスが成長してより多くの機能が含まれるようになった場合、ネストされたクラスがインターフェイスを乱雑にして、特定の何かを見つけるためにコードをふるいにかけることがわかります。また、ネストされたクラスがあるため、命名規則に違反し、クラスに小文字で名前を付ける必要があることにも気づきました（おそらくこれが選択でした）。しかし、これらの議論は実際に間違っていることよりも表面的なものです。
もちろん、具体化されていないアームを実装する必要がある場合を除きます。次に、ボディ/胴体/側面がないため、次のように腕を作成すると混乱を招きます。（紛らわしいケースにも注意してください）。
arm newArm = new Body.torso.side.arm("");私の経験では、ネストされたクラス
あなたのクラスを簡単に見て、すぐに私はそう思います：
クラスを複数のクラスに分け、それらに別々の名前空間を与えてはどうでしょう。例えば
WindowsGame1.PhysicalModel.UpperBody
WindowsGame1.PhysicalModel.LowerBody
WindowsGame1.PhysicalModel.UpperBody.Arms