class - privada - que clases internas no llevan nombre
¿Son las clases internas estáticas una buena idea o un diseño deficiente? (4)
Me parece que tengo varios lugares que tienen clases internas estáticas públicas diseñadas que amplían las clases de "ayuda", lo que hace que mi código sea mucho más seguro y, en mi opinión, legible. Por ejemplo, imagine que tengo una clase "SearchCriteria". Hay muchas cosas en común para las diferentes cosas que busco (un término de búsqueda y luego un grupo de tipos de términos de búsqueda, un rango de fechas, etc.) Extendiéndolo en una clase interna estática, aprieto bien la extensión y la búsqueda clase con las diferencias específicas. Esto parece una mala idea en teoría (Tight Coupling Bad!) Pero la extensión es específica de esta clase de búsqueda (One Class, One Purpose).
Mi pregunta es, según su experiencia, si el uso de clases internas estáticas (o cualquiera que sea el equivalente de su idioma) ha hecho que su código sea más legible / mantenible o si esto terminó mordiéndolo en el EOF.
Además, no estoy seguro de si este es el material wiki de la comunidad o no.
El punto en "acoplamiento flexible" es mantener las dos clases separadas de modo que si hay cambios de código en su clase "SearchCriteria", nada tendría que cambiar en las otras clases. Creo que las clases internas estáticas de las que estás hablando podrían hacer que mantener el código sea una pesadilla. Un cambio en SearchCriteria podría enviarte a buscar entre todas las clases estáticas para descubrir cuáles ahora están rotas debido a la actualización. Personalmente, me mantendría alejado de tales clases internas a menos que realmente lo necesite por alguna razón.
Suena perfectamente razonable para mi. Al convertirlo en una clase interna, lo hará más fácil de encontrar y un candidato obvio para revisar cuando cambie la clase de búsqueda.
El acoplamiento estricto solo es malo cuando se juntan cosas que no se corresponden realmente solo porque una de ellas llama al otro. Para las clases que colaboran estrechamente, por ejemplo, cuando, como en su caso, uno de ellos existe para apoyar al otro, entonces se llama "cohesión", y es algo bueno .
Tenga en cuenta que la clase no es la unidad de reutilización. Por lo tanto, algunos acoplamientos entre clases son normales y esperados. La unidad de reutilización suele ser una colección de clases relacionadas.
En Python, tenemos una variedad de estructuras.
Paquetes. Ellos contienen módulos. Estos son esencialmente directorios con un poco de maquinaria Python.
Módulos. Contienen clases (y funciones). Estos son archivos; y puede contener cualquier cantidad de clases estrechamente relacionadas. A menudo, el negocio de "clase interna" se maneja en este nivel.
Clases Estos pueden contener definiciones de clases internas así como también funciones de métodos. A veces (no muy a menudo) las clases internas realmente pueden ser utilizadas. Esto es raro, ya que el acoplamiento a nivel de módulo entre clases suele ser perfectamente claro.
La única advertencia al usar clases internas es asegurarse de que no se está repitiendo por todas partes, sino que, asegúrese de que, cuando defina una clase interna, no necesite usar esa funcionalidad en ningún otro lugar, y esa funcionalidad está necesariamente acoplada con la clase externa. No desea terminar con un montón de clases internas que implementen exactamente el mismo método setOrderyByNameDesc() .