大規模な C++ プロジェクトでの問題の 1 つは、ビルド時間です。依存関係ツリーの上位に作業が必要なクラスがいくつかありますが、通常は、すべてのビルドに非常に長い時間がかかるため、作業を避けます。必ずしもパブリック インターフェイスを変更する必要はありませんが、プライベート メンバーを変更する必要がある場合があります (キャッシュ変数の追加、プライベート メソッドの抽出など)。あなたが直面している問題は、C++ ではプライベート メンバーでさえパブリック ヘッダー ファイルで宣言されているため、ビルド システムですべてを再コンパイルする必要があることです。
この状況であなたは何をしますか？
私が知っている2つの解決策をスケッチしましたが、どちらにも欠点があり、まだ考えていないより良い解決策があるかもしれません.
ニキビのパターン：
ヘッダー ファイルでは、前方宣言された実装クラスへのパブリック メソッドとプライベート ポインター (pimpl ポインターまたはデリゲート) のみを宣言します。
ソースで、実装クラスを宣言し、パブリック クラスのすべてのパブリック メソッドをデリゲートに転送し、パブリック クラスのすべてのコンストラクターで pimpl クラスのインスタンスを構築します。
プラス：
マイナス：
John Lakos の『Large Scale C++ Software Design 』は、大規模な C++ プロジェクトの構築に伴う課題に対処する優れた本です。問題と解決策はすべて現実に基づいており、確かに上記の問題は詳細に議論されています。強くお勧めします。
継承の使用:
ヘッダーで、パブリック メソッドを純粋仮想メソッドおよびファクトリとして宣言します。
ソースで、インターフェイスから実装クラスを派生させて実装します。ファクトリの実装では、実装のインスタンスを返します。
プラス：
マイナス：
pimpl/handle-body イディオムをリファクタリングして使用し、純粋な仮想インターフェイスを使用して実装の詳細を非表示にすることが一般的な答えのようです。大規模なシステムを設計するときは、コンパイル時間と開発者の生産性を考慮する必要があります。しかし、ユニット テスト カバレッジのない既存の大規模な C++ システムで作業している場合はどうでしょうか。通常、リファクタリングは問題外です。
いくつかの一般的なヘッダー ファイルに触れた後、コンパイラに世界をコンパイルさせたくない場合に私が通常行うことは、再コンパイルが必要であることがわかっているファイルのみをコンパイルするメイクファイル/スクリプトを作成することです。たとえば、非仮想プライベート関数をクラスに追加する場合、ヘッダー ファイルが他の 100 のファイルに含まれている場合でも、クラスの cpp ファイルのみを再コンパイルする必要があります。その日の出発前に、世界を再構築するためのクリーン ビルドを開始します。
別のクラス B のポインターによって参照されるクラス A の前方宣言を使用できます。その後、ヘッダー ファイルではなく、クラス B の実装ファイルにクラスの A ヘッダー ファイルを含めることができます。そうすれば、クラス A に加えた変更は、クラス B のヘッダー ファイルを含むソース ファイルには影響しません。クラス A のメンバーにアクセスするクラスは、クラス A のヘッダー ファイルをインクルードする必要があります。
なし。
1つを使用することのポイントはわかりますが、次の議論は多くのシナリオでそのポイントを軽減すると思います:
もちろん、最終的には経済的な決定です。プロジェクトで「3」の重みが重要で、何らかの理由で「6」を適用できない場合は、先に進んでください。これらのテンプレートを使用すると、失うよりも多くを得ることができます。