¿Es una mala práctica tener varias clases en el mismo archivo?

Solía ​​tener una clase para un archivo. Por ejemplo car.cs tiene la clase car . Pero a medida que programo más clases, me gustaría agregarlas al mismo archivo. Por ejemplo car.cs tiene la clase car y la clase de puerta , etc.

Mi pregunta es buena para Java, C #, PHP o cualquier otro lenguaje de programación. ¿Debo intentar no tener varias clases en el mismo archivo o está bien?

Creo que deberías intentar mantener tu código en 1 clase por archivo.

Sugiero esto porque será más fácil encontrar tu clase más adelante. Además, funcionará mejor con su sistema de control de fuentes (si un archivo cambia, entonces sabrá que una clase en particular ha cambiado).

La única vez que creo que es correcto usar más de una clase por archivo es cuando está usando clases internas ... pero las clases internas están dentro de otra clase y, por lo tanto, pueden dejarse dentro del mismo archivo. Los roles de las clases internas están fuertemente relacionados con las clases externas, por lo que colocarlos en el mismo archivo está bien.

En Java, una clase pública por archivo es la forma en que funciona el lenguaje. Se puede recopilar un grupo de archivos Java en un paquete.

En Python, sin embargo, los archivos son "módulos" y, por lo general, tienen varias clases estrechamente relacionadas. Un paquete de Python es un directorio, como un paquete de Java.

Esto le da a Python un nivel adicional de agrupación entre clase y paquete.

No hay una respuesta correcta que sea independiente del idioma. Varía según el idioma.

Una clase por archivo es una buena regla, pero conviene hacer algunas excepciones. Por ejemplo, si estoy trabajando en un proyecto donde la mayoría de las clases tienen tipos de colección asociados, a menudo mantendré la clase y su colección en el mismo archivo, por ejemplo:

public class Customer { /* whatever */ }

public class CustomerCollection : List<Customer> { /* whatever */ }

La mejor regla general es mantener una clase por archivo, excepto cuando eso comience a hacer las cosas más difíciles en lugar de más fáciles. Dado que la función Buscar en archivos de Visual Studio es tan eficaz, probablemente no tendrá que dedicar mucho tiempo a examinar la estructura del archivo de todos modos.

No, no creo que sea una práctica completamente mala. Lo que quiero decir con eso es que, en general, es mejor tener un archivo separado por clase, pero definitivamente hay buenos casos de excepción en los que es mejor tener un montón de clases en un archivo. Un buen ejemplo de esto es un grupo de clases de excepción, si tiene algunas docenas de estas para un grupo dado, ¿realmente tiene sentido tener un archivo separado para cada clase de dos líneas? Yo diría que no. En este caso, tener un grupo de excepciones en una clase es, en mi humilde opinión, mucho menos engorroso y sencillo.

Descubrí que cada vez que intento combinar varios tipos en un solo archivo, siempre termino retrocediendo y separándolos simplemente porque los hace más fáciles de encontrar. Siempre que combino, siempre hay un momento en el que estoy tratando de averiguar si definí el tipo x.

Entonces, mi regla personal es que cada tipo individual (excepto quizás para las clases secundarias, por lo que significa una clase dentro de una clase, no una clase heredada) obtiene su propio archivo.

Dado que su IDE le proporciona una funcionalidad de " Navegar a " y tiene cierto control sobre el espacio de nombres dentro de sus clases, los siguientes beneficios de tener varias clases dentro del mismo archivo valen la pena para mí.

Clases para padres e hijos

En muchos casos me parece muy útil tener heredados clases dentro de su base de archivos de clase.

Entonces es bastante fácil ver qué propiedades y métodos hereda su clase secundaria y el archivo proporciona una descripción general más rápida de la funcionalidad general.

Público: Pequeño - Ayudante - Clases DTO

Cuando necesita varias clases simples y pequeñas para una funcionalidad específica, me parece bastante redundante tener un archivo con todas las referencias e incluye por solo un clase de Liner 4-8 .....

Navegación de código también es más fácil simplemente desplazándose sobre un archivo en lugar de cambiar entre 10 archivos ... También es más fácil refactorizar cuando tiene que editar solo una referencia en lugar de 10 .....

En general, romper la regla de hierro de 1 clase por archivo proporciona algo adicional libertad para organizar su código.

Lo que suceda entonces, realmente depende de su IDE, idioma, comunicación en equipo y habilidades organizativas.

Pero si quieres esa libertad, ¿por qué sacrificarla por una regla de hierro?

Si está trabajando en un equipo, mantener las clases en archivos separados facilita el control de la fuente y reduce las posibilidades de conflictos (varios desarrolladores cambian el mismo archivo al mismo tiempo). Creo que también facilita la búsqueda del código que está buscando.

La regla que siempre sigo es tener una clase principal en un archivo con el mismo nombre. Puedo o no incluir clases de ayuda en ese archivo dependiendo de qué tan estrechamente estén acopladas con la clase principal del archivo. ¿Las clases de apoyo son independientes o son útiles por sí mismas? Por ejemplo, si un método en una clase necesita una comparación especial para ordenar algunos objetos, no me molesta un poco agrupar la clase de función de comparación en el mismo archivo que el método que la usa. No esperaría usarlo en ningún otro lugar y no tiene sentido que esté solo.

Puede ser malo desde la perspectiva del desarrollo y la capacidad de mantenimiento futuros. Es mucho más fácil recordar dónde está la clase Car si tiene una clase Car.cs. ¿Dónde buscaría la clase Widget si Widget.cs no existe? ¿Es un widget de coche? ¿Es un widget de motor? Oh, tal vez sea un widget de bagel.

La única vez que considero las ubicaciones de los archivos es cuando tengo que crear nuevas clases. De lo contrario, nunca navego por la estructura de archivos. Utilizo "ir a clase" o "ir a definición".

Sé que esto es algo así como un problema de entrenamiento; Liberarse de la estructura de archivos física de los proyectos requiere práctica. Sin embargo, es muy gratificante;)

Si se siente bien ponerlos en el mismo archivo, sea mi invitado. Sin embargo, no puedo hacer eso con clases públicas en java;)

Como regla general, una clase / un archivo es el camino a seguir. Sin embargo, a menudo guardo varias definiciones de interfaz en un archivo. ¿Varias clases en un archivo? Solo si están muy estrechamente relacionados de alguna manera y son muy pequeños (<5 métodos y miembros)

Como ocurre gran parte del tiempo en la programación, depende en gran medida de la situación.

Por ejemplo, ¿cuál es la cohesión de las clases en cuestión? ¿Están estrechamente acoplados? ¿Son completamente ortogonales? ¿Están relacionados en funcionalidad?

No estaría fuera de lugar que un marco web proporcione widgets de uso general, cualquier archivo que contenga BaseWidget, TextWidget, CharWidget, etc.

Un usuario del marco no estaría fuera de lugar al definir un archivo more_widgets para contener los widgets adicionales que derivan de los widgets del marco para su espacio de dominio específico.

Cuando las clases son ortogonales y no tienen nada que ver entre sí, la agrupación en un solo archivo sería de hecho artificial. Suponga una aplicación para administrar una fábrica robótica que construye automóviles. Un archivo llamado partes que contienen CarParts y RobotParts no tendría sentido ... no es probable que haya mucha relación entre el pedido de repuestos para mantenimiento y las partes que fabrica la fábrica. Tal unión no agregaría información o conocimiento sobre el sistema que está diseñando.

Quizás la mejor regla general es no limitar sus elecciones por una regla general. Las reglas generales se crean para un análisis de primer corte o para limitar las opciones de aquellos que no son capaces de tomar buenas decisiones. Creo que a la mayoría de los programadores les gustaría creer que son capaces de tomar buenas decisiones.

Debe abstenerse de hacerlo, a menos que tenga una buena razón.

Un archivo con varias clases pequeñas relacionadas puede ser más legible que varios archivos. Por ejemplo, cuando se usan 'clases de casos', para simular tipos de unión, existe una fuerte relación entre cada clase. Usar el mismo archivo para múltiples clases tiene la ventaja de agruparlas visualmente para el lector.

En su caso, un automóvil y una puerta no parecen relacionados en absoluto, y encontrar la clase de la puerta en el archivo car.cs sería inesperado, así que no lo haga.

Una clase por archivo es más simple de mantener y mucho más clara para cualquier otra persona que vea su código. También es obligatorio o muy restringido en algunos idiomas.

En Java, por ejemplo, no puede crear varias clases de nivel superior por archivo, deben estar en archivos separados donde el nombre de la clase y el nombre del archivo son iguales.

La respuesta de Smalltalk es: no debería tener archivos (para programar). Hacen que el control de versiones y la navegación sean dolorosos.