file - oriented - ¿Es una mala práctica tener múltiples clases en el mismo archivo?
oop principles (15)
Solía tener una clase para un archivo. Por ejemplo car.cs tiene el automóvil de la clase. Pero a medida que programo más clases, me gustaría agregarlas al mismo archivo. Por ejemplo car.cs tiene el carro de clase y la clase de puerta , etc.
Mi pregunta es buena para Java, C #, PHP o cualquier otro lenguaje de programación. ¿Debería intentar no tener múltiples clases en el mismo archivo o está bien?
Como regla general, un archivo de clase / uno 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 estrechamente relacionados de alguna manera, y son muy pequeños (<5 métodos y miembros)
Como sucede la mayor 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 unidos? ¿Son completamente ortogonales? ¿Están relacionados en funcionalidad?
No estaría fuera de lugar que un marco web suministre un widgets de propósito general.cualquier archivo que contenga BaseWidget, TextWidget, CharWidget, etc.
Un usuario del framework no estaría fuera de línea al definir un archivo more_widgets para contener los widgets adicionales que derivan de los widgets de framework 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 único archivo sería artificial. Asuma una aplicación para administrar una fábrica robótica que construye automóviles. Un archivo llamado partes que contengan CarParts y RobotParts carecería de sentido ... no es probable que haya mucha relación entre el pedido de piezas de repuesto para el mantenimiento y las piezas que fabrica la fábrica. Tal unión no agregaría información o conocimiento sobre el sistema que está diseñando.
Tal vez la mejor regla general es no restringir sus elecciones por una regla general. Las reglas generales se crean para un primer análisis de corte, o para restringir las elecciones 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.
Creo que deberías tratar de mantener tu código en 1 clase por archivo.
Sugiero esto porque será más fácil encontrar tu clase más tarde. Además, funcionará mejor con su sistema de control de origen (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ás 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.
Dado que su IDE le proporciona una funcionalidad de " Navegar a " y usted tiene cierto control sobre el espacio de nombres dentro de sus clases, los beneficios a continuación de tener múltiples clases dentro del mismo archivo me valen la pena.
Clases para padres y niños
En muchos casos, me resulta bastante útil tener clases heredadas dentro de su archivo de clase base.
Entonces es bastante fácil ver qué propiedades y métodos hereda su clase secundaria y el archivo proporciona una visión general más rápida de la funcionalidad general.
Público: Small - Helper - DTO Classes
Cuando necesita varias clases simples y llanas para una funcionalidad específica, me resulta bastante redundante tener un archivo con todas las referencias e incluye solo una clase de 4 a 8 líneas ...
La navegación por 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 Iron de 1 clase por archivo proporciona cierta libertad adicional para organizar tu código.
Lo que sucede entonces, realmente depende de su IDE, idioma, comunicación de equipo y habilidades de organización.
Pero si quieres esa libertad, ¿por qué sacrificarla por una regla de hierro?
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 agruparlos visualmente para el lector.
En su caso, un automóvil y una puerta no parecen estar relacionados en absoluto, y encontrar la clase de puerta en el archivo car.cs sería inesperado, entonces no lo haga.
En Java, una clase pública por archivo es la forma en que funciona el lenguaje. Un grupo de archivos Java se puede recopilar 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 extra de agrupación entre clase y paquete.
No hay una sola respuesta correcta que sea independiente del idioma. Varía según el idioma.
He descubierto que siempre que intento combinar varios tipos en un solo archivo, siempre termino de volver y separarlos simplemente porque los hace más fáciles de encontrar. Cada vez que me combino, siempre hay un momento en el que estoy tratando de descubrir si definí el tipo x.
Así que ahora, mi regla personal es que cada tipo individual (excepto tal vez para las clases secundarias, con lo que a significa una clase dentro de una clase, no una clase heredada) obtiene su propio archivo.
La única vez que considero las ubicaciones de archivos es cuando tengo que crear nuevas clases. De lo contrario, nunca navego por la estructura de archivos. Uso "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ísicos de los proyectos requiere práctica. Sin embargo, es muy gratificante;)
Si se siente bien colocarlos en el mismo archivo, sé mi invitado. No puedo hacer eso con clases públicas en java;)
La regla que siempre uso es tener una clase principal en un archivo con el mismo nombre. Puedo o no incluir clases auxiliares en ese archivo, dependiendo de cuán estrechamente estén acopladas con la clase principal del archivo. ¿Las clases de soporte son independientes o son útiles por sí mismas? Por ejemplo, si un método en una clase necesita una comparación especial para clasificar algunos objetos, no me molesta un poco agrupar la clase de functor de comparación en el mismo archivo que el método que la usa. No esperaría usarlo en otro lado y no tiene sentido que sea solo.
La respuesta de Smalltalk es: no debe tener archivos (para programación). Hacen que las versiones y la navegación sean dolorosas.
No, no creo que sea una práctica completamente mala. Lo que quiero decir con eso es, en general, que es mejor tener un archivo por clase por separado, pero definitivamente hay buenos casos excepcionales en los que es mejor tener un grupo de clases en un archivo. Un buen ejemplo de esto es un grupo de clases de excepción, si tiene unas pocas docenas de estas para un grupo dado, ¿tiene sentido tener un archivo separado para cada clase de línea? Yo diría que no. En este caso, tener un grupo de excepciones en una clase es mucho menos engorroso y simple en mi humilde opinión.
Puede ser malo desde la perspectiva del desarrollo futuro y la mantenibilidad. Es mucho más fácil recordar dónde está la clase Car si tienes una clase Car.cs. ¿Dónde buscarías la clase Widget si Widget.cs no existe? ¿Es un widget de coche? ¿Es un widget de motor? Oh, tal vez es un widget bagel.
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 hace que sea más fácil encontrar el código que estás buscando también.
Una clase por archivo es más fácil de mantener y mucho más clara para cualquier persona que vea su código. También es obligatorio o muy restringido en algunos idiomas.
En Java, por ejemplo, no puede crear múltiples clases de nivel superior por archivo, tienen que estar en archivos separados donde el nombre de clase y el nombre de archivo son los mismos.
Una clase por archivo es una buena regla, pero es apropiado 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 de oro 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 Búsqueda en archivos de Visual Studio es tan efectiva, probablemente no tendrá que perder mucho tiempo buscando la estructura de archivos de todos modos.