Come risolvere l'interdipendenza di classe nel mio codice C ++?

Ci sono due parti nella tua domanda.

La prima parte è l'organizzazione dei file di intestazione e dei file sorgente di C ++. Questo viene risolto usando la forward statement e la separazione della dichiarazione della classe (inserendoli nel file di intestazione) e del body del metodo (inserendoli nel file sorgente). Inoltre, in alcuni casi si può applicare l' idioma Pimpl ("puntatore all'implementazione") per risolvere casi più difficili . Utilizza i puntatori della proprietà condivisa ( shared_ptr ), i puntatori a proprietà singola ( unique_ptr ) e i puntatori non proprietari (puntatore raw, ovvero "asterisco") in base alle best practice.

La seconda parte è come modellare oggetti che sono correlati tra loro sotto forma di un grafico . I grafici generali che sono not DAG (grafici aciclici diretti) non hanno un modo naturale di esprimere la proprietà di tipo ad albero. Invece, i nodi e le connessioni sono tutti i metadati che appartengono a un singolo oggetto grafico. In questo caso, non è possibile modellare la relazione nodo-connessione come aggregazioni. I nodi non "possiedono" connessioni; le connessioni non "possiedono" i nodi. Invece, sono associazioni, e sia i nodi che le connessioni sono "di proprietà" del grafico. Il grafico fornisce i metodi di interrogazione e manipolazione che operano sui nodi e sulle connessioni.

Se ti ho capito bene, lo stesso oggetto di contatto appartiene a più di un oggetto particella, poiché rappresenta una sorta di contatto fisico tra due o più particelle, giusto?

Quindi la prima cosa che penso sia discutibile è perché Particle ha una variabile membro std::vector<Contact> ? Dovrebbe invece essere std::vector<Contact*> o std::vector<std::shared_ptr<Contact> > . addContact quindi dovrebbe avere una firma diversa come addContact(Contact *cont) o addContact(std::shared_ptr<Contact> cont) invece.

Ciò rende superfluo includere "Contact.h" in "Particle.h", una dichiarazione in avanti di class Contact in "Particle.h" e una inclusione di "Contact.h" in "Particle.cpp" sarà sufficiente.

Quindi la domanda sul costruttore. Vuoi qualcosa come

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

A destra? Questo design è ok, purché il tuo programma sappia sempre le particelle correlate nel momento in cui un oggetto contatto deve essere creato.

Nota, se passi alla rotta std::vector<Contact*> , devi investire alcuni pensieri sulla durata e sulla proprietà degli oggetti Contact . Nessuna particella "possiede" i suoi contatti, probabilmente un contatto dovrà essere eliminato solo se vengono distrutti entrambi gli oggetti Particle correlati. L'utilizzo di std::shared_ptr<Contact> risolverà automaticamente questo problema. Oppure lasci che un oggetto "contesto circostante" diventi proprietario di particelle e contatti (come suggerito da @rwong) e ne gestisca la durata.

Sì, ciò che descrivi è un modo molto accettabile per garantire che ogni istanza di Contact sia presente nell'elenco di contatti di Particle .

Quello che hai fatto è corretto.

Un altro modo ... Se l'obiettivo è quello di garantire che ogni Contact sia in una lista, allora potresti:

• creazione di blocchi di Contact (costruttori privati),
• inoltra dichiara Particle class,
• crea Particle class un amico di Contact ,
• in Particle crea un metodo factory che crea un Contact

Quindi non devi includere particle.h in contact

Un'altra opzione che potresti prendere in considerazione è creare un costruttore di contatti che accetti un riferimento di particelle. Ciò consentirà a un contatto di aggiungersi a qualsiasi contenitore che implementa addContact(Contact) .

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