Clases anidadas: ¿Una herramienta útil o una violación de encapsulación?

Así que todavía no sé si debería usarlos o no.

Siento que es una violación extrema de la encapsulación, sin embargo, encuentro que soy capaz de lograr cierto grado de encapsulación al tiempo que obtengo más flexibilidad en mi código.

Proyectos Java / Swing anteriores Yo había usado clases anidadas hasta cierto punto, sin embargo, ahora me he mudado a otros proyectos en C # y estoy evitando su uso.

¿Cómo te sientes acerca de las clases anidadas?

Bueno, en pocas palabras: las clases anidadas no violan la encapsulación y, en general, las características del lenguaje no violan los principios de programación. Los programadores violan los principios de programación.

Curiosamente, se afirma que las clases anidadas aumentan la encapsulación :

Aumento de la encapsulación: considere dos clases de nivel superior, A y B, donde B necesita acceso a los miembros de A que de otro modo se declararían privados. Al ocultar la clase B dentro de la clase A, los miembros de A pueden declararse privados y B puede acceder a ellos. Además, B puede ocultarse del mundo exterior.

Hay algo de verdad en eso.

Por lo general, B es el resultado de aplicar SRP a A. B sin embargo, potencialmente viola muchos principios, especialmente si todo lo que hace es jugar con los miembros privados de A: D

Creo que las clases ocultas pueden ser útiles. Pero hay mucho potencial para el mal uso.

Usamos clases anidadas todo el tiempo. En muchas situaciones, los procesos / software empresarial tienen objetos empresariales anidados. Todos hemos visto el ejemplo de un objeto Order que tiene una colección anidada de OrderItems.

La conclusión es que facilita la lectura / escritura del código y rara vez hay un caso en el que necesite su clase de pedido y no necesite saber sobre los artículos de pedido.

Personalmente, creo que deberían evitarse, ya que acoplan su diseño de varias maneras (generalmente desfavorables).

Sin embargo, si su proyecto tiene un alcance establecido y encapsula una clase (como una clase Node o algún tipo de objeto que se utiliza para atravesar la estructura de datos de una clase específica), entonces no veo el daño.

De hecho, creo que para ciertos tipos de proyectos hace que el código (y el razonamiento) sea más legible / fácil de entender. Sin embargo, creo que para la mayoría de los proyectos con la extensibilidad en mente, es una mala idea, ya que raramente separarlos le causará problemas, pero dejarlos juntos puede obligarlo a desacoplarlos en el futuro (que es tiempo perdido).

(En C #) Generalmente los evitaría, aunque puede depender exactamente de qué propósito de la clase es.

Nunca los usaría para ningún tipo de clase de modelo de dominio, eso simplemente no tiene sentido para mí.

Solía ​​usarlos para estructurar datos que son privados en la clase externa, pero descubrí que estos casi siempre terminan siendo necesarios externamente más adelante en el ciclo de vida del proyecto, por lo que generalmente ya no me molesto más en esto.

El único momento en que los uso ahora es para el pequeño truco de codificación en el que usar otra clase pequeña facilita la implementación de una clase en particular, o la implementación de una interfaz que realmente es solo un patrón de notificación de eventos (donde la clase interna implementará una interfaz y simplemente pasa controlar de nuevo la clase externa).