Classi nidificate: uno strumento utile o una violazione dell'incapsulamento?

Quindi sono ancora sul recinto per sapere se dovrei usarli o meno.

Sento che si tratta di un'estrema violazione dell'incapsulamento, tuttavia trovo che sono in grado di raggiungere un certo grado di incapsulamento, ottenendo al contempo una maggiore flessibilità nel mio codice.

Precedenti progetti Java / Swing avevo usato classi nidificate in una certa misura, tuttavia ora sono passato ad altri progetti in C # e ne evito il loro utilizzo.

Come ti senti riguardo alle classi nidificate?

Bene, per dirla semplicemente: le classi nidificate non violano l'incapsulamento e, in generale, le funzionalità del linguaggio non violano i principi di programmazione. I programmatori violano i principi di programmazione.

Stranamente, si afferma che le classi nidificate aumentano l'incapsulamento :

Incapsulamento aumentato: considera due classi di livello superiore, A e B, in cui B ha bisogno di accedere ai membri di A che altrimenti verrebbero dichiarati privati. Nascondendo la classe B all'interno della classe A, i membri di A possono essere dichiarati privati ​​e B può accedervi. Inoltre, B stessa può essere nascosta dal mondo esterno.

C'è del vero in questo.

Di solito B è il risultato dell'applicazione dell'SRP ad A. B stesso, tuttavia potenzialmente viola molti principi, soprattutto se tutto ciò che fa è armeggiare con i membri privati ​​di A: D

Penso che le lezioni nascoste possano essere utili. Ma c'è un grande potenziale di uso improprio.

Utilizziamo sempre classi nidificate. In molte situazioni, i software / i processi aziendali hanno oggetti business nidificati. Abbiamo visto tutti l'esempio di un oggetto Order che ha una raccolta nidificata di OrderItems.

La linea di fondo è che semplifica la lettura / scrittura del codice e raramente c'è un caso in cui avresti bisogno della tua classe Order e non devi conoscere OrderItems.

Personalmente, sento che dovrebbero essere evitati poiché associano il tuo design in vari modi (generalmente sfavorevoli).

Tuttavia, se il tuo progetto ha un ambito definito e incapsula una classe (come una classe Node o una sorta di oggetto utilizzato per attraversare la struttura dati di una classe specifica), non vedo il danno.

In effetti, penso che per alcuni tipi di progetti renda il codice (e il ragionamento) più leggibile / facile da capire. Tuttavia, penso che per la maggior parte dei progetti con in mente l'estensibilità, è una cattiva idea, perché raramente separarli può causare problemi, ma lasciarli insieme potrebbe costringerti a disaccoppiarli in futuro (che è tempo sprecato).

(In C #) Generalmente li eviterei, anche se può dipendere esattamente dallo scopo della classe.

Non li userei mai per nessun tipo di classe del modello di dominio, per me non ha proprio senso.

Li usavo per strutturare i dati privati ​​nella classe esterna, ma ho scoperto che questi finiscono quasi sempre per essere necessari esternamente più avanti nel ciclo di vita del progetto, quindi generalmente non mi preoccupo più di questo.

L'unica volta che li uso ora è per il piccolo trucco di codifica strano in cui l'uso di un'altra piccola classe rende più semplice l'implementazione di una determinata classe o l'implementazione di un'interfaccia che è in realtà solo un modello di notifica di eventi (in cui la classe interna implementerà un'interfaccia e semplicemente passa controllare indietro la classe esterna).