Comment résoudre l'interdépendance des classes dans mon code C ++?

Dans mon projet C ++, j'ai deux classes, Particleet Contact. Dans la Particleclasse, j'ai une variable membre std::vector<Contact> contactsqui contient tous les contacts d'un Particleobjet, et les fonctions membres correspondantes getContacts()et addContact(Contact cont). Ainsi, dans "Particle.h", j'inclus "Contact.h".

Dans la Contactclasse, je voudrais ajouter du code au constructeur pour Contactcet appel Particle::addContact(Contact cont), afin qu'il contactssoit mis à jour pour les deux Particleobjets entre lesquels l' Contactobjet est ajouté. Ainsi, je devrais inclure "Particle.h" dans "Contact.cpp".

Ma question est de savoir si cela est acceptable / bonne pratique de codage et, sinon, quelle serait une meilleure façon de mettre en œuvre ce que j'essaie d'atteindre (simplement mettre à jour automatiquement la liste des contacts pour une particule spécifique chaque fois qu'un nouveau contact est créé).

Ces classes seront liées entre elles par une Networkclasse qui aura N particules ( std::vector<Particle> particles) et Nc contacts ( std::vector<Contact> contacts). Mais je voulais pouvoir avoir des fonctions comme particles[0].getContacts()- est-ce correct d'avoir de telles fonctions dans la Particleclasse dans ce cas, ou y a-t-il une meilleure "structure" d'association en C ++ à cet effet (de deux classes liées utilisées dans une autre classe) .

J'ai peut-être besoin d'un changement de perspective ici dans la façon dont j'aborde cette question. Étant donné que les deux classes sont connectées par un Networkobjet de classe, est-ce une organisation de code / classe typique d'avoir des informations de connectivité entièrement contrôlées par l' Networkobjet (en ce qu'un objet Particle ne devrait pas être au courant de ses contacts et, par conséquent, il ne devrait pas avoir de getContacts()membre une fonction). Ensuite, afin de savoir quels contacts a une particule spécifique, j'aurais besoin d'obtenir ces informations via l' Networkobjet (par exemple, en utilisant network.getContacts(Particle particle)).

Serait-il moins typique (peut-être même découragé) de concevoir une classe C ++ pour un objet Particle d'avoir également ces connaissances (c'est-à-dire, avoir plusieurs façons d'accéder à ces informations - via l'objet Network ou l'objet Particle, selon ce qui semble le plus pratique) )?

Votre question comporte deux parties.

La première partie est l'organisation des fichiers d'en-tête C ++ et des fichiers source. Ceci est résolu en utilisant la déclaration directe et la séparation de la déclaration de classe (en les plaçant dans le fichier d'en-tête) et du corps de la méthode (en les plaçant dans le fichier source). De plus, dans certains cas, on peut appliquer l' idiome Pimpl ("pointeur vers l'implémentation") pour résoudre des cas plus difficiles. Utilisez des pointeurs de propriété partagée ( shared_ptr), des pointeurs de propriété unique ( unique_ptr) et des pointeurs non propriétaires (pointeur brut, c'est-à-dire «astérisque») conformément aux meilleures pratiques.

La deuxième partie est de savoir comment modéliser des objets qui sont interdépendants sous la forme d'un graphique . Les graphiques généraux qui ne sont pas des DAG (graphiques acycliques dirigés) n'ont pas un moyen naturel d'exprimer la propriété arborescente. Au lieu de cela, les nœuds et les connexions sont tous des métadonnées qui appartiennent à un seul objet graphique. Dans ce cas, il n'est pas possible de modéliser la relation nœud-connexion sous forme d'agrégations. Les nœuds ne "possèdent" pas de connexions; les connexions ne "possèdent" pas de nœuds. Au lieu de cela, ce sont des associations, et les nœuds et les connexions appartiennent au graphique. Le graphique fournit des méthodes de requête et de manipulation qui opèrent sur les nœuds et les connexions.

Si je vous comprends bien, le même objet de contact appartient à plus d'un objet de particules, car il représente une sorte de contact physique entre deux ou plusieurs particules, non?

La première chose que je pense est sujette à caution est pourquoi Particlea une variable membre std::vector<Contact>? Ce devrait être un std::vector<Contact*>ou un à la std::vector<std::shared_ptr<Contact> >place. addContactdevrait alors avoir une signature différente comme addContact(Contact *cont)ou à la addContact(std::shared_ptr<Contact> cont)place.

Il n'est donc pas nécessaire d'inclure "Contact.h" dans "Particle.h", une déclaration directe de class Contactdans "Particle.h" et une inclusion de "Contact.h" dans "Particle.cpp" seront suffisantes.

Ensuite, la question sur le constructeur. Tu veux quelque chose comme

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

Droite? Cette conception est correcte, tant que votre programme connaît toujours les particules associées au moment où un objet contact doit être créé.

Remarquez que si vous std::vector<Contact*> route, vous devez réfléchir à la durée de vie et à la propriété des Contactobjets. Aucune particule ne "possède" ses contacts, un contact ne devra probablement être supprimé que si les deux Particleobjets associés sont détruits. Utiliser à la std::shared_ptr<Contact>place résoudra automatiquement ce problème. Ou vous laissez un objet "contexte environnant" s'approprier les particules et les contacts (comme suggéré par @rwong) et gérer leur durée de vie.

Oui, ce que vous décrivez est un moyen très acceptable de garantir que chaque Contactinstance figure dans la liste des contacts de a Particle.

Ce que vous avez fait est correct.

Une autre façon ... Si le but est de s'assurer que tout Contactest dans une liste, alors vous pourriez:

• bloquer la création de Contact (constructeurs privés),
• déclarer en avant Particle classe,
• faire de la Particleclasse un ami deContact ,
• à Particlecréer une méthode d'usine qui crée unContact

Ensuite, vous n'avez pas à inclure particle.hdanscontact

Une autre option que vous pourriez envisager est de faire du constructeur Contact qui accepte une référence de particule un modèle. Cela permettra à un contact de s'ajouter à n'importe quel conteneur qui implémente addContact(Contact).

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