Más allá de argumentos hipotéticos y enfocándose en Windows .NET con Visual Studio IDE y proyectos de software en crecimiento, tiene sentido en este contexto tener una clase por archivo.
En general, para referencia visual, nada supera una clase por archivo. De Verdad.
No sé si Microsoft hace o no lo mismo, sin embargo, crearon la partialpalabra clave para dividir una clase en varios archivos (esto es aún más grave). A menudo se usa para dividir el código de diseñador generado automáticamente de su código personalizado en la misma clase (pero a veces se usa para permitir que diferentes desarrolladores trabajen en la clase al mismo tiempo a través de diferentes archivos). Por lo tanto, Microsoft ve los beneficios de múltiples archivos y todos tienen en mente múltiples ideas de organización de archivos con seguridad con .NET.
Para las clases anidadas no tiene más remedio que usar un archivo, o al menos las primeras partes de las clases en ellas. Un archivo es necesario y está bien en este caso:
class BicycleWheel {
class WheelSpoke {
}
}
De lo contrario, ¿por qué mantendría múltiples clases en un archivo? El argumento "porque son pequeños" o asociados entre sí sí no retiene mucha agua porque eventualmente sus clases se asociarán con otras clases. En última instancia, no se puede inferir fácilmente la organización en el archivo de los objetos en función de su uso, especialmente a medida que el software continúa creciendo.
Además, si usa carpetas para espacios de nombres , nunca tendrá un choque de nombre de archivo de clase. También es conveniente ubicar una clase por nombre de archivo en el sistema de archivos cuando no está dentro de un entorno de desarrollo como Visual Studio (por ejemplo, si desea editar rápidamente una clase con el Bloc de notas o algo rápido / ligero ).
Tantas buenas razones ...