Jak rozwiązać współzależność klas w moim kodzie C ++?

W moim projekcie C ++ mam dwie klasy Particlei Contact. W Particleklasie mam zmienną składową, std::vector<Contact> contactsktóra zawiera wszystkie kontakty Particleobiektu oraz odpowiednie funkcje składowe getContacts()i addContact(Contact cont). Zatem w „Particle.h” dołączam „Contact.h”.

W Contactklasie chciałbym dodać kod do konstruktora, aby Contactten wywołał Particle::addContact(Contact cont), aby contactsbył aktualizowany zarówno dla Particleobiektów, między którymi Contactobiekt jest dodawany. Dlatego musiałbym dołączyć „Particle.h” do „Contact.cpp”.

Moje pytanie brzmi, czy jest to akceptowalna / dobra praktyka kodowania, a jeśli nie, jaki byłby lepszy sposób na wdrożenie tego, co próbuję osiągnąć (po prostu, automatycznie aktualizując listę kontaktów dla określonej cząstki za każdym razem, gdy nowy kontakt jest tworzone).

Klasy te zostaną połączone razem Networkklasą, która będzie miała cząsteczki N ( std::vector<Particle> particles) i styki Nc ( std::vector<Contact> contacts). Ale chciałem particles[0].getContacts()mieć takie funkcje - czy Particlew tym przypadku można mieć takie funkcje w klasie, czy też istnieje lepsza „struktura” asocjacji w C ++ do tego celu (z dwóch powiązanych klas używanych w innej klasie) .

Może potrzebuję zmiany perspektywy w tym, w jaki sposób do tego podchodzę. Ponieważ obie klasy są połączone przez Networkobiekt klasy, czy typową organizacją kodu / klasy jest posiadanie przez Networkobiekt pełnej kontroli informacji o łączności (w tym sensie, że obiekt cząstek nie powinien być świadomy swoich kontaktów, a zatem nie powinien mieć getContacts()członka funkcjonować). Następnie, aby wiedzieć, jakie kontakty ma konkretna cząstka, musiałbym uzyskać tę informację przez Networkobiekt (np. Za pomocą network.getContacts(Particle particle)).

Czy mniej typowy (być może nawet zniechęcony) projekt klasy C ++ dla obiektu Particle miałby również tę wiedzę (tj. Miałby wiele sposobów dostępu do tych informacji - za pośrednictwem obiektu Network lub obiektu Particle, w zależności od tego, co wydaje się wygodniejsze )?

Twoje pytanie składa się z dwóch części.

Pierwsza część to organizacja plików nagłówkowych C ++ i plików źródłowych. Aby rozwiązać ten problem, należy użyć deklaracji forward i oddzielić deklarację klasy (umieszczając je w pliku nagłówkowym) i treść metody (umieszczając je w pliku źródłowym). Ponadto w niektórych przypadkach można zastosować idiom Pimpl („wskaźnik do implementacji”), aby rozwiązać trudniejsze przypadki. Używaj wskaźników współwłasności ( shared_ptr), wskaźników pojedynczego prawa własności ( unique_ptr) i wskaźników niebędących właścicielami (wskaźnik nieprzetworzony, tj. „Gwiazdka”) zgodnie z najlepszymi praktykami.

Druga część dotyczy modelowania obiektów powiązanych ze sobą w formie wykresu . Ogólne wykresy, które nie są DAG (ukierunkowane wykresy acykliczne), nie mają naturalnego sposobu wyrażania własności drzewiastych. Zamiast tego wszystkie węzły i połączenia są metadanymi należącymi do jednego obiektu wykresu. W takim przypadku nie można modelować relacji połączenie-węzeł jako agregacji. Węzły nie „posiadają” połączeń; połączenia nie „posiadają” węzłów. Zamiast tego są to skojarzenia, a zarówno węzły, jak i połączenia są „własnością” wykresu. Wykres przedstawia metody zapytań i manipulacji, które działają na węzłach i połączeniach.

Jeśli dobrze zrozumiałem, ten sam obiekt kontaktowy należy do więcej niż jednego obiektu cząsteczkowego, ponieważ reprezentuje pewien rodzaj fizycznego kontaktu między dwiema lub więcej cząsteczkami, prawda?

Pierwszą rzeczą, która moim zdaniem jest wątpliwa, jest to, dlaczego Particlezmienna członkowska jest zmienna std::vector<Contact>? Powinien to być a std::vector<Contact*>lub std::vector<std::shared_ptr<Contact> >zamiast. addContactpowinien mieć inny podpis, jak addContact(Contact *cont)lub addContact(std::shared_ptr<Contact> cont)zamiast.

To sprawia, że ​​dołączanie „Contact.h” w „Particle.h” nie jest konieczne, wystarczy deklaracja class Contact„w. Particle.h” i dołączenie „Contact.h” w „Particle.cpp”.

Następnie pytanie o konstruktora. Chcesz coś takiego

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

Dobrze? Ten projekt jest w porządku, o ile twój program zawsze zna powiązane cząstki w momencie, w którym trzeba utworzyć obiekt kontaktowy.

Uwaga: jeśli wybierzesz std::vector<Contact*>trasę, musisz zainwestować kilka przemyśleń na temat żywotności i własności Contactobiektów. Żadna cząstka nie jest właścicielem swoich kontaktów, kontakt prawdopodobnie będzie musiał zostać usunięty tylko wtedy, gdy oba powiązane Particleobiekty zostaną zniszczone. Użycie std::shared_ptr<Contact>zamiast tego automatycznie rozwiąże ten problem. Albo pozwalasz obiektowi „otaczającemu kontekstowi” przejąć własność cząstek i kontaktów (jak sugeruje @rwong) i zarządzać ich żywotnością.

Tak, to, co opisujesz, jest bardzo akceptowalnym sposobem upewnienia się, że każda Contactinstancja znajduje się na liście kontaktów Particle.

To, co zrobiłeś, jest poprawne.

Inny sposób ... Jeśli celem jest upewnienie się, że każdy Contactznajduje się na liście, możesz:

• tworzenie bloków Contact(konstruktorów prywatnych),
• przekaż Particleklasę,
• uczyń Particleklasę przyjacielem Contact,
• w Particletworzeniu metody fabrycznej, która tworzyContact

Więc nie musisz się particle.hw to włączaćcontact

Inną opcją, którą możesz rozważyć, jest utworzenie konstruktora Contact, który akceptuje szablon Particle referencyjny. Umożliwi to kontaktowi dodanie się do dowolnego implementowanego kontenera addContact(Contact).

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