¿Cómo resolver la interdependencia de clases en mi código C ++?

En mi proyecto C ++, tengo dos clases, Particley Contact. En la Particleclase, tengo una variable miembro std::vector<Contact> contactsque contiene todos los contactos de un Particleobjeto, y las funciones miembro correspondientes getContacts()y addContact(Contact cont). Por lo tanto, en "Particle.h", incluyo "Contact.h".

En la Contactclase, me gustaría agregar código al constructor para Contactque se llame Particle::addContact(Contact cont), de modo que contactsse actualice para los dos Particleobjetos entre los que Contactse agrega el objeto. Por lo tanto, tendría que incluir "Particle.h" en "Contact.cpp".

Mi pregunta es si esto es aceptable o buena práctica de codificación y, de lo contrario, cuál sería una mejor manera de implementar lo que estoy tratando de lograr (simplemente, actualizar automáticamente la lista de contactos para una partícula específica cada vez que un nuevo contacto es creado).

Estas clases estarán unidas por una Networkclase que tendrá N partículas ( std::vector<Particle> particles) y Nc contactos ( std::vector<Contact> contacts). Pero quería poder tener funciones como particles[0].getContacts(): ¿está bien tener tales funciones en la Particleclase en este caso, o hay una mejor "estructura" de asociación en C ++ para este propósito (de dos clases relacionadas que se utilizan en otra clase)? .

Es posible que necesite un cambio de perspectiva aquí en cómo me estoy acercando a esto. Dado que las dos clases están conectadas por un Networkobjeto de clase, es típico que la organización de código / clase tenga información de conectividad totalmente controlada por el Networkobjeto (en el sentido de que un objeto Particle no debe conocer sus contactos y, en consecuencia, no debe tener un getContacts()miembro función). Entonces, para saber qué contactos tiene una partícula específica, necesitaría obtener esa información a través del Networkobjeto (por ejemplo, usando network.getContacts(Particle particle)).

¿Sería menos típico (quizás incluso desalentado) el diseño de clase C ++ para que un objeto Particle también tenga ese conocimiento (es decir, tenga múltiples formas de acceder a esa información, ya sea a través del objeto Network o el objeto Particle, lo que sea más conveniente) )?

Hay dos partes en su pregunta.

La primera parte es la organización de los archivos de encabezado C ++ y los archivos fuente. Esto se resuelve mediante el uso de la declaración directa y la separación de la declaración de clase (colocándolos en el archivo de encabezado) y el cuerpo del método (colocándolos en el archivo fuente). Además, en algunos casos se puede aplicar el lenguaje Pimpl ("puntero a la implementación") para resolver casos más difíciles. Utilice punteros de propiedad compartida ( shared_ptr), punteros de propiedad única ( unique_ptr) y punteros no propietarios (puntero sin formato, es decir, el "asterisco") de acuerdo con las mejores prácticas.

La segunda parte es cómo modelar objetos que están interrelacionados en forma de gráfico . Los gráficos generales que no son DAG (gráficos acíclicos dirigidos) no tienen una forma natural de expresar la propiedad de un árbol. En cambio, los nodos y las conexiones son todos metadatos que pertenecen a un único objeto gráfico. En este caso, no es posible modelar la relación nodo-conexión como agregaciones. Los nodos no "poseen" conexiones; las conexiones no "poseen" nodos. En cambio, son asociaciones, y tanto los nodos como las conexiones son "propiedad" del gráfico. El gráfico proporciona métodos de consulta y manipulación que operan en los nodos y las conexiones.

Si lo entendí bien, el mismo objeto de contacto pertenece a más de un objeto de partículas, ya que representa algún tipo de contacto físico entre dos o más partículas, ¿verdad?

Entonces, lo primero que creo que es cuestionable es ¿por qué Particletiene una variable miembro std::vector<Contact>? Debería ser a std::vector<Contact*>o a std::vector<std::shared_ptr<Contact> >en su lugar. addContactentonces debería tener una firma diferente como addContact(Contact *cont)o en su addContact(std::shared_ptr<Contact> cont)lugar.

Esto hace innecesario incluir "Contact.h" en "Particle.h", class Contactserá suficiente una declaración de "Particle.h" y una inclusión de "Contact.h" en "Particle.cpp".

Luego la pregunta sobre el constructor. Quieres algo como

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

¿Derecho? Este diseño está bien, siempre que su programa siempre conozca las partículas relacionadas en el momento en que se debe crear un objeto de contacto.

Tenga en cuenta que si va por la std::vector<Contact*>ruta, debe invertir algunas ideas sobre la vida útil y la propiedad de los Contactobjetos. Ninguna partícula "posee" sus contactos, un contacto probablemente tendrá que eliminarse solo si Particlese destruyen ambos objetos relacionados . Usar en su std::shared_ptr<Contact>lugar resolverá este problema automáticamente. O deja que un objeto de "contexto circundante" tome posesión de partículas y contactos (como lo sugiere @rwong), y gestiona su vida útil.

Sí, lo que describe es una forma muy aceptable de garantizar que cada Contactinstancia esté en la lista de contactos de a Particle.

Lo que has hecho es correcto.

Otra forma ... Si el objetivo es asegurar que todos Contactestén en una lista, entonces usted podría:

• creación de bloques de Contact(constructores privados),
• adelante declarar Particleclase,
• hacer que Particlela clase de un amigo Contact,
• en Particlecrear un método de fábrica que crea unContact

Entonces no tienes que incluir particle.hencontact

Otra opción que puede considerar es hacer que el constructor de contactos que acepte una referencia de partícula tenga una plantilla. Esto permitirá que un contacto se agregue a cualquier contenedor que implemente addContact(Contact).

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