Cómo organizar Interfaces/clases/implementaciones en el proyecto

Question

Encontré algunas preguntas sobre cómo organizar proyectos (espacio de nombres, una clase por archivo, etc.), pero en una nota más específica, ¿cómo organizas "cosas" que son muy estrechamente relacionado?

Por lo general terminan con:

• un interfazIMyStuff
• una base (a veces abstracta) de clase que proporciona skeletton básica para esa interfaz: BaseMyStuff
• clases de implementaciónMyStuffWithBellsAndWhistles , MyStuffWithChocolateFlavours

Parece lógico que estén en el mismo espacio de nombres, pero parece que mis carpetas comienzan a estar un poco abarrotadas si pongo todos estos archivos en la misma carpeta (no es realmente un problema real, pero se siente extraño).

¿Sería correcto definir tanto la interfaz como la clase base en el mismo archivo?

O ¿estaría bien agrupar esas cosas en subcarpetas, pero en el mismo espacio de nombres? de esta manera:

-MyNamespace 
|-Interfaces 
    | -IMyStuff 
    | -IMyOtherStuff 
|-BaseClasses 
    | -BaseMyStuff 
    | -BaseMyOtherStuff 
|-Implementation 
    | -MyStuffWithAwesomeBehaviour 
    | -MyStuffWithGreatUsefulness 
    | -MyOtherStuffSoNeatYouWillCry 

¿Cuáles son las "mejores prácticas" con respecto a este tipo de organización?

Answer 1

Si el propósito de las interfaces es abstraer la implementación y permitir implementaciones alternativas que no son conocidas por el autor de la interfaz, entonces recomendaría mantenerlas en un archivo de proyecto separado. Al construir proyectos de pruebas unitarias u otros consumidores de la interfaz, esto les permitirá crear una referencia de proyecto que incluya solo las interfaces y no las implementaciones. Esto significa que las implementaciones alternativas de clases concretas nunca necesitan tener una referencia a la representación concreate original.