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

Nel mio progetto C ++, ho due classi Particlee Contact. Nella Particleclasse, ho una variabile membro std::vector<Contact> contactsche contiene tutti i contatti di un Particleoggetto e le corrispondenti funzioni membro getContacts()e addContact(Contact cont). Pertanto, in "Particle.h" includo "Contact.h".

Nella Contactclasse, vorrei aggiungere il codice al costruttore per Contactquello che chiamerà Particle::addContact(Contact cont), in modo che contactsvenga aggiornato per entrambi gli Particleoggetti tra i quali Contactviene aggiunto l' oggetto. Quindi, dovrei includere "Particle.h" in "Contact.cpp".

La mia domanda è se questo sia accettabile o meno una buona pratica di codifica e, in caso contrario, quale sarebbe un modo migliore per implementare ciò che sto cercando di ottenere (in poche parole, aggiornando automaticamente l'elenco dei contatti per una particella specifica ogni volta che un nuovo contatto è creato).

Queste classi saranno legate insieme da una Networkclasse che avrà N particelle ( std::vector<Particle> particles) e contatti Nc ( std::vector<Contact> contacts). Ma volevo essere in grado di avere funzioni come particles[0].getContacts()- va bene avere tali funzioni nella Particleclasse in questo caso, oppure esiste una "struttura" di associazione migliore in C ++ per questo scopo (di due classi correlate usate in un'altra classe) .

Potrei aver bisogno di un cambiamento di prospettiva qui nel modo in cui mi sto avvicinando a questo. Dato che le due classi sono connesse da un Networkoggetto class, è tipica dell'organizzazione codice / classe avere informazioni di connettività interamente controllate Networkdall'oggetto (in quanto un oggetto Particle non dovrebbe essere a conoscenza dei suoi contatti e, di conseguenza, non dovrebbe avere un getContacts()membro funzione). Quindi, per sapere quali contatti ha una specifica particella, avrei bisogno di ottenere tali informazioni attraverso l' Networkoggetto (ad esempio, usando network.getContacts(Particle particle)).

Sarebbe meno tipico (forse anche scoraggiato) il design della classe C ++ per un oggetto Particle anche avere quella conoscenza (cioè avere più modi per accedere a tali informazioni - attraverso l'oggetto Network o l'oggetto Particle, a seconda di quale sembra più conveniente )?

Ci sono due parti nella tua domanda.

La prima parte è l'organizzazione dei file di intestazione C ++ e dei file di origine. Ciò viene risolto utilizzando la dichiarazione diretta e la separazione della dichiarazione di classe (inserendole nel file di intestazione) e del corpo del metodo (inserendole nel file di origine). Inoltre, in alcuni casi si può applicare il linguaggio Pimpl ("puntatore all'implementazione") per risolvere casi più difficili. Utilizzare i puntatori di proprietà condivisa ( shared_ptr), i puntatori di proprietà singola ( unique_ptr) e i puntatori non proprietari (puntatore non elaborato, ovvero l'asterisco) in base alle best practice.

La seconda parte è come modellare oggetti collegati tra loro sotto forma di un grafico . I grafici generali che non sono DAG (grafici aciclici diretti) non hanno un modo naturale di esprimere la proprietà simile ad un albero. Al contrario, i nodi e le connessioni sono tutti 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" nodi. Al contrario, sono associazioni e entrambi i nodi e le connessioni sono "di proprietà" del grafico. Il grafico fornisce metodi di query e manipolazione che operano su nodi e connessioni.

Se ho capito bene, lo stesso oggetto di contatto appartiene a più di un oggetto particella, dal momento che rappresenta un tipo di contatto fisico tra due o più particelle, giusto?

Quindi la prima cosa che ritengo discutibile è perché Particleha una variabile membro std::vector<Contact>? Dovrebbe essere un std::vector<Contact*>o un std::vector<std::shared_ptr<Contact> >invece. addContactquindi 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", class Contactsarà sufficiente una dichiarazione in avanti di "Particle.h" e una inclusione di "Contact.h" in "Particle.cpp".

Quindi la domanda sul costruttore. Vuoi qualcosa di simile

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

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

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

Sì, quello che descrivi è un modo molto accettabile per garantire che ogni Contactistanza sia nell'elenco dei contatti di a Particle.

Quello che hai fatto è corretto.

Un altro modo ... Se l'obiettivo è quello di garantire che tutti Contactsiano in un elenco, è possibile:

• blocco della creazione di Contact(costruttori privati),
• dichiarare in avanti la Particleclasse,
• fare della Particleclasse un amico di Contact,
• in Particlecrea un metodo factory che crea aContact

Quindi non c'è bisogno di includere particle.hincontact

Un'altra opzione che potresti prendere in considerazione è rendere il costruttore del contatto che accetta un riferimento a una particella come modello. Ciò consentirà a un contatto di aggiungersi a qualsiasi contenitore implementato addContact(Contact).

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