División en archivos: ¿cuánto se divide?

9

Si digo que tengo un marco jerárquico de entidad, en lugar de un modelo de componente. Algo así como:
(Sí, esto está inventado)

Arma-> Pistola-> Pistola automática-> MP44
O, más de un ejemplo clásico:
Entidad-> MovableEntity-> Enemy-> WalkingEnemy

¿Hasta qué punto dividiría los archivos de origen / encabezado para facilitar la lectura y la organización? ¿Es mejor usar algo como Entity.cpp, MovableEntity.cpp, Enemy.cpp, etc., o sería mejor un enfoque como Entity.cpp [que contiene Entity and MovableEntity] y Enemy.cpp [que contiene Enemy y WalkingEnemy]? (¿O de una manera más independiente del lenguaje, un archivo Enemigo y un archivo de Entidad frente a un archivo para cada clase?)
Además, ¿afectaría esto a otra cosa que no sea la legibilidad y la organización?

c++ file

— El pato comunista
fuente

1

Nitpicky, pero no creo que language-agnosticsea una etiqueta apropiada, ya que depende en gran medida del lenguaje que esté utilizando en cuanto a los efectos secundarios.

— Tetrad el

Buen punto, creo que puedo volver a etiquetar.

— El pato comunista el

12

Esto es completamente una cuestión de preferencia. Sin embargo, personalmente creo que es mejor errar al lado de más archivos. Java requiere una clase por archivo , con el nombre del archivo igual que el nombre de la clase, por ejemplo; lo hacen por política para hacer cumplir esta buena práctica (aunque puede tener subclases que básicamente eviten esto).

Además, los sistemas de control de código fuente son bastante buenos para combinar cambios en un archivo, pero es menos complicado si solo está trabajando en archivos totalmente separados. También puede ver más fácilmente quién cambió qué clase. Digamos que otro desarrollador realiza un cambio en el archivo AllEntities.h; no tienes idea de qué entidad (o entidades) cambió exactamente hasta que abres el archivo y miras la salida diff.

Sin embargo, es genial agrupar pequeñas estructuras y enumeraciones relacionadas con la clase dentro del archivo de una clase . Si tiene una enumeración que solo usa una sola clase, ¿por qué dividirla en su propio archivo? Solo póngalos juntos. Pero si lo usa otra clase (es decir, otro miembro de la clase es del tipo de esta enumeración), es cuando es el momento de darle su propio archivo.

— Ricket
fuente

Convenido. La complejidad de sus tipos definitivamente debería ser un factor. Si su lenguaje admite clases parciales (o si las implementaciones de miembros se pueden organizar de manera similar a C ++), incluso recomendaría dividir tipos particularmente complejos en múltiples archivos. Por ejemplo, si hay una interfaz (grande) que su clase debe implementar, pero el código es bastante genérico y no es terriblemente relevante para el resto, puede dividir ese código en un archivo separado / clase parcial. Para los tipos de enumeración, creo que podría salirse con la colocación de todas las enumeraciones para un espacio de nombres dado dentro de un solo archivo.

— Mike Strobel el

1

¿Agrupar sus enumeraciones no significa que cambiar un solo valor causaría una recompilación de cada archivo que usa una enumeración en ese espacio de nombres?

— El pato comunista el

Bueno, eso realmente depende del idioma, pero sí, ciertamente podría tener ese efecto. Realmente no es un problema para mí, ya que desarrollo principalmente en C # (sin compilación de archivo por archivo), pero podría ser problemático en C ++ y otros lenguajes. Como siempre, hay factores específicos del idioma a considerar, y ese sería uno de ellos :).

— Mike Strobel el

2

Muchos lenguajes fuera de C / C ++ imponen restricciones a los archivos. Ricket mencionó 'una clase por archivo' de Java; Python usa archivos como espacios de nombres; otros idiomas a menudo copian el espíritu de aquellos.

Si está utilizando C o C ++, más archivos incluidos generalmente significan tiempos de compilación más largos por archivo; Por otro lado, menos significa más para volver a compilar al hacer pequeños cambios. Debido a que las enumeraciones no se pueden declarar hacia adelante en C, siempre debe colocarlas en archivos de encabezado que contengan solo otras enumeraciones, por razones de dependencia.

De lo contrario, "un archivo por clase" de Java es razonable, pero durante mucho tiempo Java ha admitido clases internas, como un contenedor y una clase interna de su iterador. De manera similar, en cualquier otro idioma, es probable que desee un registro / estructura / clase / tipo / interfaz / blorb dominante por encabezado, pero puede decidir incluir también ayudantes o contenedores relacionados.

(No necesita usar un modelo de componente, pero si tiene una jerarquía de clase profunda y específica como esa, se odiará más tarde).

Estaba usando la jerarquía como ejemplo; Sentí que enfatizaba lo que quise decir mejor. En el código real, me esfuerzo por los componentes.

— El pato comunista el