Le classi nidificate sono sottovalutate?

Non definirei questo "meccanismo di progettazione raramente utilizzato", almeno non universalmente: sebbene esistano negozi in cui alcuni contributori possono disapprovare l'uso di classi nidificate, questa non è affatto una caratteristica oscura.

Sebbene l'esistenza di classi con visibilità dell'assemblaggio e l'introduzione di lambda abbia significativamente ridotto la necessità di classi nidificate ^* , rimangono una scelta di progettazione valida. Sebbene vi sia una certa sovrapposizione con le classi interne all'interno di uno spazio dei nomi, la funzione delle classi nidificate è unica nel farti nascondere una classe interamente all'interno di un'altra classe.

^* L'uso di una funzionalità simile in Java è molto più alto, perché altre alternative disponibili in C # non sono presenti in Java.

Considera per un momento che stai scrivendo una lezione in un'altra classe, che non sarà mai usata da nessun'altra parte nel tuo programma. Perché se lo usassi altrove, lo renderebbe una normale classe pubblica, proprio come tutti gli altri.

Quindi la cosa che dovrebbe fare grande OOP (riusabilità) è assente qui. Inoltre, cosa potresti ottenere con una classe nidificata che non potresti ottenere con i metodi normali e i membri privati all'interno della classe genitore?

Per un utile modello di software che utilizza classi nidificate, guarda qui .

am I going down an inherintly bad path

Penso che nel tuo secondo esempio (le sottoclassi di worker) lo sei sicuramente. Hai mappato ciascuna sottoclasse in uno stato specifico nella super classe. Così ora ogni volta che vuoi aggiungere uno stato alla super classe devi cambiare le posizioni tre (aggiungi lo stato alla super classe, aggiungi una nuova sottoclasse e cambia il costruttore di derivato classe per aggiungere sottoclassi alla lista).

L'uso di classi nidificate per accedere ai membri privati sembra essere un uso valido (non l'ho mai fatto personalmente) ma il tuo caso specifico non funziona qui.

Come per l'esempio di parte del corpo. Poiché tutte le classi nidificate sono pubbliche, in realtà non stai facendo molto eccetto il namespacing. Se queste classi crescono per includere più funzionalità, potresti semplicemente scoprire che le classi nidificate ingombrano solo le interfacce e stai setacciando il codice per trovare qualcosa di specifico. Ho notato anche che, poiché hai classi annidate, sei costretto a violare le convenzioni sui nomi e dare un nome alle tue classi con lettere minuscole (forse questa era una scelta). Ma questi argomenti sono più superficiali di qualsiasi cosa veramente sbagliata.

A meno che, naturalmente, non fosse necessario implementare un braccio disincarnato. Quindi creare un braccio facendo quanto segue è fonte di confusione perché non c'è corpo / busto / lato. (Notare anche l'involucro confuso).

arm newArm = new Body.torso.side.arm("");

L'unico vantaggio che posso pensare alle classi annidate è che possono essere rese private (o protette). Direi che in questo caso le classi annidate possono aiutarti a incapsulare se una classe è destinata ad essere utilizzata dalla classe esterna e da quella classe.

Nella mia esperienza, classi annidate

• È tornato a perseguitarmi
• Sono stati usati quando volevo tagliare gli angoli
• Fatto testare un incubo
• Ha avuto un impatto negativo sulla separazione delle preoccupazioni e sulla progettazione generale

Ho dato una breve occhiata alla tua classe, e subito penso che:

• È doloroso guardarlo perché la classe è enorme
• Non riesco a testare "le dita" senza creare praticamente tutto il corpo
• Non posso avere più implementazioni di torso. Non sembra ovvio in un contesto di "corpo umano", ma in uno scenario diverso questo sarebbe ovvio.

Perché non separare la tua classe in più classi e assegnare loro spazi dei nomi separati. Per es.

WindowsGame1.PhysicalModel.UpperBody
WindowsGame1.PhysicalModel.LowerBody
WindowsGame1.PhysicalModel.UpperBody.Arms