Cerco di evitare le classi interne in generale a meno che non siano semplici lambda, ascoltatori con una o due righe di codice, ecc.
Una volta che una classe interiore ha una vita propria ed esegue funzioni più complesse, la refactoring nella sua classe di alto livello. Userò un'interfaccia standard o la creerò per la classe che ha usato per racchiuderla ( A ). Quindi costruisco la classe B e passa un riferimento all'interfaccia che A implementa e viene utilizzato da B .
Sebbene A e B siano strettamente accoppiati, probabilmente non è necessario che lo siano. Separare quell'accoppiamento e utilizzare interfacce e riferimenti piuttosto che un puntatore / riferimento% implicito di classe esterna% co_de significa ora che this è un passo più vicino alla riusabilità. C'è una astrazione tra di loro.
Spesso la ragione per introdurre un'altra classe è che la classe che racchiude deve svolgere un lavoro aggiuntivo che non può fare da sé. È probabile che tale lavoro aggiuntivo (secondo la mia esperienza) violi il principio di responsabilità singola . Spostarlo in una classe interiore è un passo per risolverlo, ma è (secondo me) una soluzione non ottimale. Refactoring come ho detto sopra risolverà i problemi di accoppiamento stretto e di "responsabilità multipla".
Un ultimo motivo per dividere in più classi di primo livello è che riduce i file di origine. Questo non ha nulla a che fare con i principi OOP ed è puramente estetico.