C ++コードでクラスの相互依存を解決するにはどうすればよいですか？

私のC ++プロジェクトには、2つのクラスとがParticleありContactます。でParticleクラス、Iは、メンバ変数有するstd::vector<Contact> contactsのすべての連絡先含まParticleオブジェクトを、対応するメンバ関数をgetContacts()とaddContact(Contact cont)。したがって、「Particle.h」には「Contact.h」を含めます。

ではContact、クラス、私はのためのコンストラクタにコードを追加したいContactことが呼び出すParticle::addContact(Contact cont)ように、contacts両方のために更新されてParticleいる間でオブジェクトContactオブジェクトが追加されています。したがって、「Contact.cpp」に「Particle.h」を含める必要があります。

私の質問は、これが許容できる/適切なコーディングプラクティスであるかどうかであり、そうでない場合は、達成しようとしていることを実装するためのより良い方法は何ですか（簡単に言えば、新しい連絡先のたびに特定の粒子の連絡先のリストを自動的に更新します）創造された）。

これらのクラスは、NetworkN個の粒子（std::vector<Particle> particles）とNc個の接触（std::vector<Contact> contacts）を持つクラスによって結合されます。しかし、私は次のような関数を使用できるようにしたかったのです。この場合、クラスにparticles[0].getContacts()そのような関数があっても大丈夫ですParticleか、またはこの目的のためにC ++でより良い関連付け「構造」があります（別のクラスで使用されている2つの関連クラスの） 。

私はこれにどのように取り組んでいるのか、ここで視点のシフトが必要かもしれません。2つのクラスはNetworkクラスオブジェクトによって接続されているため、接続情報をNetworkオブジェクトによって完全に制御するのが一般的なコード/クラス編成ですか（パーティクルオブジェクトはその連絡先を認識してはならず、その結果、getContacts()メンバーを持つべきではありません）関数）。次に、特定の粒子が何に接触しているかを知るために、Networkオブジェクトを介して（たとえばを使用してnetwork.getContacts(Particle particle)）その情報を取得する必要があります。

Particleオブジェクトがその知識を持つこと（つまり、NetworkオブジェクトまたはParticleオブジェクトのいずれかを介して、その情報にアクセスするための複数の方法があること）は、あまり一般的ではない（おそらく推奨されない）C ++クラス設計でしょうか）？

質問には2つの部分があります。

最初の部分は、C ++ヘッダーファイルとソースファイルの構成です。これは、前方宣言とクラス宣言（ヘッダーファイルに置く）とメソッド本体（ソースファイルに置く）を分離することで解決されます。さらに、場合によっては、Pimplイディオム（「実装へのポインター」）を適用して、より難しいケースを解決することができます。ベストプラクティスに従って、共有所有者ポインター（shared_ptr）、単一所有者ポインター（unique_ptr）、および非所有ポインター（生のポインター、つまり「アスタリスク」）を使用します。

2番目の部分は、相互に関連するオブジェクトをグラフの形でモデル化する方法です。DAG ではない一般的なグラフ（有向非循環グラフ）には、ツリーのような所有権を自然に表現する方法がありません。代わりに、ノードと接続はすべて、単一のグラフオブジェクトに属するメタデータです。この場合、ノード接続関係を集約としてモデル化することはできません。ノードは接続を「所有」しません。接続はノードを「所有」しません。代わりに、これらは関連付けであり、ノードと接続の両方がグラフによって「所有」されます。グラフは、ノードと接続を操作するクエリと操作のメソッドを提供します。

正解ですが、同じ接触オブジェクトは複数のパーティクルオブジェクトに属しています。これは、2つ以上のパーティクル間の何らかの物理的接触を表すためですよね？

だから私が疑問に思う最初のものは、なぜParticleメンバー変数があるのstd::vector<Contact>ですか？代わりにa std::vector<Contact*>またはa std::vector<std::shared_ptr<Contact> >にする必要があります。addContact次に、addContact(Contact *cont)またはaddContact(std::shared_ptr<Contact> cont)代わりに別の署名が必要です。

これにより、「Particle.h」に「Contact.h」をインクルードする必要がなくなり、「Particle.h」に前方宣言がありclass Contact、「Particle.cpp」に「Contact.h」をインクルードするだけで十分です。

次に、コンストラクタについての質問。あなたはのようなものが欲しい

 Contact(Particle &p1, Particle &p2)
 {
      p1.addContact(this);
      p2.addContact(this);
 }

正しい？この設計は問題ありませんが、接触オブジェクトを作成する必要がある時点で、プログラムが関連するパーティクルを常に認識している必要があります。

std::vector<Contact*>ルートに行く場合は、Contactオブジェクトの存続期間と所有権についていくらか考えなければならないことに注意してください。連絡先を「所有」するパーティクルはありません。連絡先は、関連Particleする両方のオブジェクトが破壊された場合にのみ削除する必要があります。std::shared_ptr<Contact>代わりにを使用すると、この問題が自動的に解決されます。または、「周囲のコンテキスト」オブジェクトにパーティクルと連絡先（@rwongによって提案されたような）の所有権を取得させ、その存続期間を管理させます。

はい、あなたが説明することは、すべてのContactインスタンスがの連絡先のリストに含まれることを保証する非常に許容できる方法ですParticle。

あなたがしたことは正しいです。

別の方法...すべてContactがリストにあることを確認することを目的とする場合、次のことができます。

• Contact（プライベートコンストラクタ）の作成をブロックします。
• 前方宣言Particleクラス、
• メイクParticleクラスの友人Contact、
• でParticle作成するファクトリメソッドを作成しますContact

そして、あなたは含める必要はありませんparticle.hでcontact

考えられるもう1つのオプションは、パーティクル参照を受け入れるContactコンストラクターを作成することです。これにより、Contactはを実装するコンテナに自分自身を追加できますaddContact(Contact)。

template<class Container>
Contact(/*parameters*/, Container& container)
{
  container.addContact(*this);
}