モジュールAとBが 2 つしかない場合の最も簡単なケースのみを扱うことができます。
AはBに依存しているので、 Bをライブラリとしてビルドし、 Bのヘッダー ファイルをAにインクルードし、 AをビルドするときにBライブラリにもリンクします。
これは、AとBが相互に依存している場合には機能せず、モジュールの数が増えるとさらに悪化します..
では、モジュール化された開発を実行する一般的な方法はc/c++何ですか?
アップデート
申し訳ありませんが、私のタイトルが不正確なようです。言い換えたバージョンは次のとおりです。モジュールを多く.hの.cppファイルに分割するにはどうすればよいですか (単一のファイルではなく)?
A と B が相互に依存している場合、それらを個別に展開することはできません。したがって、実際には 2 つではなく 1 つのモジュールを使用します。(ただし、モジュールをリファクタリングして、共通のものを 3 番目のモジュール C に抽出することができます。したがって、A と B の両方が C に依存するが、互いに依存することはありません。)
適切に設計されたプロジェクトには、周期的なモジュールの依存関係が含まれていません。これにより、モジュール間に常に適切なビルド順序が存在することが保証されます。
モジュールを多くの .h および .cpp ファイル (単一のファイルではなく) に分割するにはどうすればよいですか?
基本的な原則は、モジュール レベルの原則と非常によく似ています。循環的な依存関係と重複した定義を避けることです。@Felixは、これに不可欠なツールである前方宣言とインクルードガードについてすでに言及しました。また、トピックをより深く理解するために、@kotlinski が推奨する Larman の本を 2 番目に使用することもできます。
優れた設計を学ぶには練習が必要です。最初のアプローチが完璧に見えなくてもあきらめないでください :-) C++ では、変更後の過剰な再コンパイルが特に苦痛です。これを最小限に抑えるには、最も依存するもの (クラス、ヘッダー) が変更される頻度が最も低いものになるように努めてください。つまり、具体的な実装ではなく、インターフェイス (抽象クラス) に依存します。
また、論理パーティション (クラス/コンポーネント) と物理パーティション (ヘッダー/cpp ファイル) の間の健全な関係を維持するように努めてください。一般的な方法は、すべてのクラス定義を個別のヘッダー ファイルに配置し、その実装 (該当する場合) を個別の cpp ファイルに配置することです。ただし、論理的な関係を強調するために、1 つのヘッダーで密結合クラス (コンポーネント) を定義することをお勧めします。
一般的に言えば、相互に依存する 2 つのモジュールを持つことは設計上の臭いです。次のいずれかを実行できます
1) モジュールを新しいモジュール C にマージする、または
2) 共通のサブセットを I に抽出し、A と B が I に依存するが相互に依存しないようにします。
アップデート
前方宣言と #pragma once または #include/#ifndef 保護を使用します。
解決策は、モジュールが有向非巡回グラフを形成することを確認することです...つまり、A が B に依存している場合、B が A に依存していないことを確認してください。多くの規律が必要ですが、長期的には価値があります。
このことに興味がある場合は、Large Scale C++ Software Designをよく読んでください。
Model–View–Controller - MVCなどのデザイン パターン。
Model-View-Controller (MVC) はソフトウェア アーキテクチャであり、1現在、ソフトウェア エンジニアリングで使用されるアーキテクチャ パターンと見なされています。このパターンは、「ドメイン ロジック」 (ユーザーのアプリケーション ロジック) を入力と表示 (UI) から分離し、それぞれの独立した開発、テスト、および保守を可能にします。
