El ejemplo que diste está realmente bien en mi opinión. Está declarando clases internas , por lo que es perfectamente sensato mantenerlas en el mismo archivo . La única forma de evitar esto sería convertir su Items
clase en una clase parcial y dividirla en varios archivos. Consideraría esta mala práctica. Mi política general para las clases anidadas es que deben ser pequeñas y privadas. Hay dos excepciones a esto:
- está diseñando un grupo de clases (más común en el objetivo-c), por lo tanto, puede ser sensato usar el enfoque de clase parcial
- necesita una enumeración que solo se utiliza con la API pública de la clase principal. En este caso, prefiero que se declare una enumeración pública dentro de la clase principal en lugar de contaminar mi espacio de nombres. El enum siendo un "enum interno" resulta efectivamente en darle un alcance bien definido.
Si formula la pregunta de manera un poco diferente y pregunta "¿Debería poner cada clase de nivel de espacio de nombres en su propio archivo", entonces mi respuesta sería "sí".
Al diseñar las clases respetamos el Principio de responsabilidad única. Leer el código se vuelve mucho más fácil si su forma sigue su semántica, por lo tanto, dividir archivos por clase es sensato.
Desde un punto de vista mecánico, tener un archivo por clase tiene varias ventajas. Puede abrir varias clases al mismo tiempo en diferentes ventanas. Esto es especialmente importante ya que ningún desarrollador serio trabaja con menos de dos pantallas. Ser capaz de tener más contexto frente a mi cabeza significa que puedo mantener más contexto en mi cabeza. (La mayoría de los IDE le permitirán abrir el mismo archivo dos veces, pero esto me resulta incómodo).
El siguiente aspecto importante es el control de origen y la fusión. Al mantener sus clases separadas, evita muchas molestias cuando se realizan cambios en el mismo archivo porque las clases separadas deben cambiarse.