Wie löse ich die Interdependenz von Klassen in meinem C ++ - Code?

In meinem C ++ - Projekt habe ich zwei Klassen Particleund Contact. In der ParticleKlasse habe ich eine Mitgliedsvariable, std::vector<Contact> contactsdie alle Kontakte eines ParticleObjekts sowie die entsprechenden Mitgliedsfunktionen getContacts()und enthält addContact(Contact cont). Daher füge ich in "Partikel.h" "Kontakt.h" ein.

In der ContactKlasse möchte ich dem Konstruktor Code für Contactdiesen Aufruf hinzufügen Particle::addContact(Contact cont), damit dieser contactsfür beide ParticleObjekte aktualisiert wird , zwischen denen das ContactObjekt hinzugefügt wird. Daher müsste ich "Particle.h" in "Contact.cpp" aufnehmen.

Meine Frage ist, ob dies eine akzeptable / gute Codierungspraxis ist oder nicht, und wenn nicht, was wäre ein besserer Weg, um das zu implementieren, was ich erreichen möchte (einfach ausgedrückt, die Liste der Kontakte für ein bestimmtes Partikel wird bei jedem neuen Kontakt automatisch aktualisiert geschaffen).

Diese Klassen werden durch eine NetworkKlasse mit N Partikeln ( std::vector<Particle> particles) und Nc Kontakten ( std::vector<Contact> contacts) miteinander verbunden. Aber ich wollte in der Lage sein, Funktionen zu haben wie particles[0].getContacts()- ist es Particlein diesem Fall in Ordnung, solche Funktionen in der Klasse zu haben , oder gibt es in C ++ zu diesem Zweck eine bessere Assoziationsstruktur (von zwei verwandten Klassen, die in einer anderen Klasse verwendet werden)? .

Möglicherweise brauche ich hier einen Perspektivwechsel in meiner Herangehensweise. Da die beiden Klassen durch ein NetworkKlassenobjekt verbunden sind, ist es eine typische Code- / Klassenorganisation, Konnektivitätsinformationen vollständig vom NetworkObjekt steuern zu lassen (insofern sollte ein Partikelobjekt seine Kontakte nicht kennen und folglich kein getContacts()Mitglied haben Funktion). Um dann zu wissen, welche Kontakte ein bestimmtes Teilchen hat, müsste ich diese Informationen über das NetworkObjekt erhalten (z network.getContacts(Particle particle). B. mit ).

Wäre es weniger typisch (vielleicht sogar entmutigt), ein C ++ - Klassendesign für ein Partikelobjekt zu haben, dieses Wissen ebenfalls zu haben (dh mehrere Möglichkeiten zu haben, auf diese Informationen zuzugreifen - entweder über das Netzwerkobjekt oder das Partikelobjekt, je nachdem, was bequemer erscheint )?

Ihre Frage besteht aus zwei Teilen.

Der erste Teil ist die Organisation von C ++ - Header- und Quelldateien. Dies wird gelöst, indem die Vorwärtsdeklaration und die Trennung der Klassendeklaration (Einfügen in die Header-Datei) und des Methodenkörpers (Einfügen in die Quelldatei) verwendet werden. Darüber hinaus kann man in einigen Fällen das Pimpl-Idiom ("Zeiger auf die Implementierung") anwenden , um schwierigere Fälle zu lösen. Verwenden Sie Zeiger mit gemeinsamem Besitz ( shared_ptr), Zeiger mit einzelnem Besitz ( unique_ptr) und Zeiger ohne Besitz (Rohzeiger, dh das "Sternchen") gemäß den Best Practices.

Im zweiten Teil werden Objekte modelliert, die in Form eines Diagramms miteinander verknüpft sind . Allgemeine Diagramme, die keine DAGs sind (gerichtete azyklische Diagramme), haben keine natürliche Art, baumartigen Besitz auszudrücken. Stattdessen sind die Knoten und Verbindungen alle Metadaten, die zu einem einzelnen Diagrammobjekt gehören. In diesem Fall ist es nicht möglich, die Knoten-Verbindungs-Beziehung als Aggregationen zu modellieren. Knoten "besitzen" keine Verbindungen; Verbindungen "besitzen" keine Knoten. Stattdessen handelt es sich um Zuordnungen, und sowohl Knoten als auch Verbindungen gehören dem Diagramm. Das Diagramm enthält Abfrage- und Manipulationsmethoden, die auf den Knoten und Verbindungen ausgeführt werden.

Wenn ich Sie richtig verstanden habe, gehört dasselbe Kontaktobjekt zu mehr als einem Partikelobjekt, da es eine Art physischen Kontakt zwischen zwei oder mehr Partikeln darstellt, oder?

Das erste, was ich für fragwürdig halte, ist, warum Particlees eine Mitgliedsvariable gibt std::vector<Contact>. Es sollte stattdessen ein std::vector<Contact*>oder ein sein std::vector<std::shared_ptr<Contact> >. addContactdann sollte eine andere Signatur wie addContact(Contact *cont)oder addContact(std::shared_ptr<Contact> cont)stattdessen haben.

Dies macht es unnötig, "Contact.h" in "Particle.h" aufzunehmen, eine Vorwärtsdeklaration von class Contact"Particle.h" und ein Include von "Contact.h" in "Particle.cpp" sind ausreichend.

Dann die Frage nach dem Konstruktor. Du willst so etwas wie

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

Recht? Dieses Design ist in Ordnung, solange Ihr Programm die zugehörigen Partikel immer zu dem Zeitpunkt kennt, zu dem ein Kontaktobjekt erstellt werden muss.

Beachten Sie, dass Sie, wenn Sie den std::vector<Contact*>Weg gehen , einige Gedanken über die Lebensdauer und den Besitz der ContactObjekte investieren müssen . Kein Partikel "besitzt" seine Kontakte, ein Kontakt muss wahrscheinlich nur gelöscht werden, wenn beide verwandten ParticleObjekte zerstört sind. Wenn Sie std::shared_ptr<Contact>stattdessen verwenden, wird dieses Problem automatisch für Sie gelöst. Oder Sie lassen ein "umgebenden Kontext" -Objekt das Eigentum an Partikeln und Kontakten übernehmen (wie von @rwong vorgeschlagen) und deren Lebensdauer verwalten.

Ja, was Sie beschreiben, ist eine sehr akzeptable Methode, um sicherzustellen, dass jede ContactInstanz in der Kontaktliste von a enthalten ist Particle.

Was Sie getan haben, ist richtig.

Ein anderer Weg ... Wenn das Ziel darin besteht, sicherzustellen, dass jeder Contactin einer Liste enthalten ist, können Sie:

• Blockerstellung von Contact(privaten Konstruktoren),
• vorwärts deklarieren ParticleKlasse,
• mach die ParticleKlasse zu einem Freund von Contact,
• in Particleerstellen Sie eine Factory-Methode, die eine erstelltContact

Dann müssen Sie nicht enthalten particle.hincontact

Eine weitere Option, die Sie in Betracht ziehen könnten, besteht darin, den Kontaktkonstruktor so zu gestalten, dass eine Vorlage mit Partikelreferenz akzeptiert wird. Auf diese Weise kann sich ein Kontakt zu jedem Container hinzufügen, der implementiert wird addContact(Contact).

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