Fractionnement en fichiers - combien de fractionnement?

Si je dis que j'ai un cadre d'entité hiérarchique, plutôt qu'un modèle de composant. Quelque chose comme:
(Oui, c'est inventé)

Weapon-> Gun-> AutomaticGun-> MP44
Ou, plus d'un exemple classique:
Entity-> MovableEntity-> Enemy-> WalkingEnemy

Dans quelle mesure diviseriez-vous les fichiers source / en-tête pour la lisibilité et l'organisation? Est-il préférable d'aller quelque chose comme Entity.cpp, MovableEntity.cpp, Enemy.cpp, etc. ou une approche comme Entity.cpp [contenant Entity et MovableEntity] et Enemy.cpp [contenant Enemy et WalkingEnemy] serait-elle meilleure? (Ou d'une manière plus indépendante de la langue, un fichier ennemi et un fichier d'entité par rapport à un fichier pour chaque classe?)
De plus, cela affecterait-il autre chose que la lisibilité et l'organisation?

C'est entièrement une question de préférence. Cependant, je pense personnellement qu'il vaut mieux se tromper du côté de plusieurs fichiers. Java nécessite une classe par fichier , avec le nom de fichier identique au nom de classe, par exemple; ils le font par politique pour appliquer cette bonne pratique (bien que vous puissiez avoir des sous-classes qui contournent essentiellement cela).

De plus, les systèmes de contrôle de source sont assez bons pour fusionner les modifications dans un fichier, mais c'est moins compliqué si vous travaillez uniquement dans des fichiers totalement séparés. Vous pouvez également voir plus facilement qui a changé de classe. Supposons qu'un autre développeur modifie le fichier AllEntities.h; vous n'avez aucune idée exactement de quelle entité (ou entités) il a changé jusqu'à ce que vous ouvriez le fichier et que vous regardiez la sortie diff.

C'est génial de regrouper les petites structures et énumérations liées à la classe dans le fichier d'une classe , cependant. Si vous avez une énumération qui n'est utilisée que par une seule classe, pourquoi la diviser en son propre fichier? Mettez-les ensemble. Mais s'il est utilisé par une autre classe (c'est-à-dire qu'un autre membre de la classe est du type de cette énumération), c'est alors qu'il est temps de lui donner son propre fichier.

De nombreux langages en dehors de C / C ++ imposent des contraintes sur les fichiers. Ricket a mentionné «une classe par fichier» de Java; Python utilise des fichiers comme espaces de noms; d'autres langues copient souvent l'esprit de celles-ci.

Si vous utilisez C ou C ++, plus de fichiers inclus signifie généralement des temps de compilation plus longs par fichier; d'un autre côté, moins signifie plus à recompiler lors de petits changements. Étant donné que les énumérations ne peuvent pas être déclarées en aval en C, vous devez toujours les placer dans des fichiers d'en-tête contenant uniquement d'autres énumérations, pour des raisons de cohérence.

Sinon, "un fichier par classe" de Java est raisonnable, mais pendant longtemps Java a pris en charge les classes internes - comme un conteneur, et une classe interne de son itérateur. De même, dans toute autre langue, vous voudrez probablement un enregistrement / structure / classe / type / interface / blorb dominant par en-tête, mais vous pouvez également décider d'inclure des assistants ou des conteneurs associés.

(Vous n'avez pas besoin d'utiliser un modèle de composant, mais si vous avez une hiérarchie de classe approfondie et spécifique comme celle-là, vous allez vous détester plus tard.)