Quindi sono ancora sul punto di decidere se dovrei usarli o meno.
Ritengo che sia una violazione estrema dell'incapsulamento, tuttavia trovo che sono in grado di raggiungere un certo grado di incapsulamento, guadagnando nel contempo maggiore flessibilità nel mio codice.
Progetti precedenti di Java / Swing In qualche misura avevo usato classi annidate, tuttavia ora mi sono spostato in altri progetti in C # e sto evitando il loro uso.
Come ti senti riguardo alle classi annidate?
Bene, lo dico anche semplicemente: le classi annidate non violano l'incapsulamento e, in generale, le caratteristiche linguistiche non violano i principi di programmazione. I programmatori violano i principi di programmazione.
Stranamente, si sostiene che le classi annidate aumentino l'incapsulamento :
Increased encapsulation—Consider two top-level classes, A and B, where B needs access to members of A that would otherwise be declared private. By hiding class B within class A, A's members can be declared private and B can access them. In addition, B itself can be hidden from the outside world.
C'è del vero in questo.
Solitamente B è il risultato dell'applicazione di SRP a A. B in sé, tuttavia potenzialmente viola molti principi, specialmente se tutti fa gingillare con i membri privati di A: D
Penso che le classi nascoste possano essere utili. Ma c'è un grande potenziale di abuso.
Utilizziamo sempre classi annidate. In molte situazioni, i processi / software aziendali hanno oggetti di business annidati. Abbiamo visto tutti l'esempio di un oggetto Order che ha una collezione nidificata di OrderItems.
La linea di fondo è che rende più facile la lettura / scrittura del codice e raramente vi è il caso in cui avresti bisogno della tua classe Order e non hai bisogno di sapere su OrderItem.
Personalmente, ritengo che dovrebbero essere evitati poiché accoppiano il tuo design in vari modi (solitamente sfavorevoli).
Tuttavia, se il progetto ha un ambito impostato e incapsula una classe (come una classe nodo o un qualche tipo di oggetto che è utilizzato per attraversare la struttura dati di una classe specifica), allora non vedo il danno.
In effetti, penso che per certi tipi di progetti rende il codice (e il ragionamento) più leggibile / facile da capire. Tuttavia, penso che per la maggior parte dei progetti con estensibilità in mente, è una cattiva idea, perché raramente li separerà causandoti problemi, ma lasciandoli insieme potrebbe costringerti a disaccoppiarli in futuro (che è tempo sprecato).
(In C #) In genere li eviterei, sebbene possa dipendere esattamente da quale sia lo scopo della classe.
Non li userei mai per qualsiasi tipo di classe di modello di dominio, che non ha senso per me.
Li usavo per strutturare i dati che sono privati nella classe esterna, ma ho scoperto che questi quasi sempre finiscono per essere necessari esternamente più avanti nel ciclo di vita del progetto quindi di solito non mi preoccupo più di questo .
L'unica volta che li uso ora è per lo strano piccolo trucco di codifica in cui l'uso di un'altra piccola classe rende più semplice l'implementazione di una particolare classe, o l'implementazione di un'interfaccia che è in realtà solo un pattern di notifica di eventi (dove la classe interna implementerà un'interfaccia e passa semplicemente il controllo indietro alla classe esterna).
Leggi altre domande sui tag object-oriented encapsulation class