ファイルに分割-どのくらいの分割ですか？

私が言うなら、コンポーネントモデルではなく、階層的なエンティティフレームワークがあります。のようなもの：（
はい、これは構成されています）

武器->銃->自動銃-> MP44
または、より古典的な例：
Entity-> MovableEntity-> Enemy-> WalkingEnemy

読みやすさと整理のために、ソースファイルとヘッダーファイルをどのくらい分けますか？Entity.cpp、MovableEntity.cpp、Enemy.cppなどのようにするのが最善ですか、それともEntity.cpp [EntityとMovableEntityを含む]やEnemy.cpp [EnemyとWalkingEnemyを含む]などのアプローチの方が良いでしょうか。（または、より言語にとらわれない方法で、EnemyファイルとEntityファイルではなく、各クラスのファイルですか？）
また、これは可読性と編成以外に影響しますか？

これは完全に好みの問題です。ただし、個人的には、ファイルを増やすことをお勧めします。Javaでは、ファイルごとに1つのクラスが必要です。たとえば、ファイル名はクラス名と同じです。彼らはポリシーによってこれを行い、この良い習慣を実施します（ただし、基本的にこれを回避するサブクラスを持つことができます）。

また、ソースコントロールシステムは、ファイル内の変更をマージするのに優れていますが、完全に別のファイルで作業している場合は、それほど面倒ではありません。また、誰がどのクラスを変更したかを簡単に確認できます。別の開発者がAllEntities.hファイルを変更するとします。ファイルを開いてdiff出力を確認するまで、彼が変更したエンティティを正確に知る手掛かりはありません。

ただし、クラスに関連する小さな構造体と列挙型を1つのクラスのファイル内にグループ化すると便利です。単一のクラスでのみ使用される列挙型がある場合、それを独自のファイルに分割するのはなぜですか？組み合わせるだけです。しかし、それが別のクラスで使用されている場合（つまり、別のクラスメンバーがこの列挙型である場合）は、独自のファイルを与えるときです。

C / C ++以外の多くの言語は、ファイルに制約を課しています。リケットは、Javaの「ファイルごとに1つのクラス」について言及しました。Pythonはファイルを名前空間として使用します。他の言語はそれらの精神をしばしばコピーします。

CまたはC ++を使用している場合、一般的に含まれるファイルが多いほど、ファイルごとのコンパイル時間が長くなります。一方、数が少ないと、小さな変更を加えたときに再コンパイルする量が多くなります。列挙型はCで前方宣言できないため、依存関係の健全性のために、常に他の列挙型のみを含むヘッダーファイルに列挙を配置する必要があります。

それ以外の場合、Javaの「クラスごとに1つのファイル」は妥当ですが、Javaは長い間、コンテナのような内部クラスとその反復子の内部クラスをサポートしてきました。同様に、他の言語では、ヘッダーごとに1つの主要なレコード/構造体/クラス/タイプ/インターフェース/ブロブが必要になりますが、関連するヘルパーまたはコンテナーも含めることもできます。

（コンポーネントモデルを使用する必要はありませんが、そのような深い特定のクラス階層がある場合は、後で自分を嫌うことになります。）