如何解决我的C ++代码中的类相互依赖性？

在我的C ++项目中，我有两个类，Particle和Contact。在Particle该类中，我有一个成员变量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”。

我的问题是这是否可接受/良好的编码习惯，如果不能，那么哪种更好的方式来实现我要实现的目标（简单地说，每当有新联系人时，自动更新特定粒子的联系人列表）被建造）。

这些类别将由Network具有N个粒子（std::vector<Particle> particles）和Nc个接触（std::vector<Contact> contacts）的类别联系在一起。但是我希望能够拥有类似的功能particles[0].getContacts()– Particle在这种情况下可以在类中使用这样的功能，还是为此目的在C ++中有更好的关联“结构”（在另一个类中使用两个相关类） 。

在此方面，我可能需要转变看法。由于这两个类是由一个Network类对象连接的，因此典型的代码/类组织是具有完全由该Network对象控制的连接信息（因为Particle对象不应知道其联系，因此，它不应具有getContacts()成员）功能）。然后，为了知道特定粒子具有什么接触，我将需要通过Network对象（例如使用network.getContacts(Particle particle)）获得该信息。

具有粒子粒子知识的C ++类设计是否也不太典型（也许甚至不鼓励），也就是（具有通过网络对象或粒子粒子访问信息的多种方式），无论哪种方式看起来更方便）？

您的问题分为两部分。

第一部分是C ++头文件和源文件的组织。这可以通过使用前向声明以及将类声明（将它们放入头文件中）和方法主体（将它们放入源文件中）分开来解决。此外，在某些情况下，可以应用Pimpl习惯用法（“实现的指针”）来解决更困难的情况。根据最佳实践shared_ptr，使用共享所有权指针（），单所有权指针（unique_ptr）和非所有权指针（原始指针，即“星号”）。

第二部分是如何以图的形式对相互关联的对象进行建模。不是 DAG的常规图（有向无环图）没有表达树状所有权的自然方法。相反，节点和连接都是属于单个图形对象的所有元数据。在这种情况下，无法将节点连接关系建模为聚合。节点不“拥有”连接；连接不“拥有”节点。相反，它们是关联，并且节点和连接都由图“拥有”。该图提供了对节点和连接进行操作的查询和操作方法。

如果我理解正确，那么同一接触对象属于多个粒子对象，因为它表示两个或多个粒子之间的某种物理接触，对吗？

因此，我认为值得怀疑的第一件事就是为什么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

您可能考虑的另一种选择是使Contact构造函数接受模板化的Particle引用。这将允许Contact将自身添加到实现的任何容器中addContact(Contact)。

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