Как разрешить взаимозависимость классов в моем коде C ++?

В моем проекте C ++ у меня есть два класса, Particleи Contact. В Particleклассе, у меня есть переменная - член std::vector<Contact> contacts, содержащий все контакты Particleобъекта, а также соответствующие функции - члены getContacts()и addContact(Contact cont). Таким образом, в «Particle.h» я включаю «Contact.h».

В Contactклассе я хотел бы добавить код в конструктор, Contactкоторый будет вызывать Particle::addContact(Contact cont), чтобы contactsон обновлялся для обоих Particleобъектов, между которыми Contactдобавляется объект. Таким образом, я должен был бы включить «Particle.h» в «Contact.cpp».

Мой вопрос заключается в том, является ли это приемлемой / хорошей практикой кодирования и, если нет, каков будет лучший способ реализовать то, что я пытаюсь достичь (проще говоря, автоматически обновляя список контактов для конкретной частицы при каждом новом контакте создано).

Эти классы будут связаны вместе Networkклассом, который будет иметь N частиц ( std::vector<Particle> particles) и Nc контактов ( std::vector<Contact> contacts). Но я хотел иметь возможность иметь такие функции, как particles[0].getContacts()- нормально ли иметь такие функции в Particleклассе в этом случае, или для этой цели существует лучшая ассоциативная «структура» в C ++ (из двух связанных классов, используемых в другом классе) ,

Мне может понадобиться сдвиг перспективы здесь, как я подхожу к этому. Поскольку два класса связаны между собой Networkобъектом класса, это типичная организация кода / класса, когда информация о соединении полностью контролируется Networkобъектом (в том смысле, что объект Particle не должен знать о своих контактах и, следовательно, он не должен иметь getContacts()члена функция). Затем, чтобы узнать, какие контакты имеет конкретная частица, мне нужно было бы получить эту информацию через Networkобъект (например, используя network.getContacts(Particle particle)).

Будет ли менее типичным (возможно, даже не поощряемым) дизайн класса C ++ для объекта Particle также обладать этими знаниями (т. Е. Иметь несколько способов доступа к этой информации - через объект Network или объект Particle, в зависимости от того, что кажется более удобным) )?

В вашем вопросе есть две части.

Первая часть - это организация заголовочных файлов C ++ и исходных файлов. Это решается с помощью предварительного объявления и разделения объявления класса (помещая их в файл заголовка) и тела метода (помещая их в исходный файл). Кроме того, в некоторых случаях можно применять идиому Pimpl («указатель на реализацию») для решения более сложных случаев. Используйте указатели совместного владения ( shared_ptr), указатели единоличного владения ( unique_ptr) и не владеющие указатели (необработанный указатель, то есть «звездочка») в соответствии с лучшими практиками.

Вторая часть состоит в том, как моделировать объекты, которые связаны между собой в форме графика . Обычные графы, которые не являются группами DAG (ориентированные ациклические графы), не имеют естественного способа выражения древовидной принадлежности. Вместо этого все узлы и соединения являются метаданными, которые принадлежат одному объекту графа. В этом случае невозможно смоделировать отношения узел-соединение как агрегации. Узлы не «владеют» соединениями; соединения не «владеют» узлами. Вместо этого они являются ассоциациями, и оба узла и соединения «принадлежат» графу. На графике представлены методы запросов и манипуляций, которые работают с узлами и соединениями.

Если я вас правильно понял, один и тот же контактный объект принадлежит более чем одному объекту частиц, поскольку он представляет собой своего рода физический контакт между двумя или более частицами, верно?

Итак, первое, что я считаю сомнительным, - это почему Particleпеременная-член std::vector<Contact>? Это должно быть std::vector<Contact*>или std::vector<std::shared_ptr<Contact> >вместо. addContactтогда должна иметь другую подпись как addContact(Contact *cont)или addContact(std::shared_ptr<Contact> cont)вместо.

Это делает ненужным включение «Contact.h» в «Particle.h», предварительное объявление class Contactв «Particle.h» и включение «Contact.h» в «Particle.cpp» будет достаточно.

Тогда вопрос о конструкторе. Вы хотите что-то вроде

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

Правильно? Этот дизайн в порядке, если ваша программа всегда знает связанные частицы в тот момент, когда должен быть создан контактный объект.

Обратите внимание, что если вы идете по этому std::vector<Contact*>пути, вы должны инвестировать некоторые мысли о сроке службы и владении Contactобъектами. Никакая частица не "владеет" своими контактами, контакт, вероятно, придется удалять только в случае Particleразрушения обоих связанных объектов. Использование std::shared_ptr<Contact>вместо этого решит эту проблему для вас автоматически. Или вы позволяете объекту «окружающего контекста» брать на себя ответственность за частицы и контакты (как это было предложено @rwong) и управлять их временем жизни.

Да, то, что вы описываете, является очень приемлемым способом гарантировать, что каждый Contactэкземпляр находится в списке контактов a Particle.

То, что вы сделали, правильно.

Другой способ ... Если цель состоит в том, чтобы каждый из Contactних был в списке, то вы могли бы:

• блок создания Contact(частные конструкторы),
• вперед объявляю Particleкласс,
• сделать Particleкласс другом Contact,
• в Particleсоздании фабричного метода, который создаетContact

Тогда вам не нужно включать particle.hвcontact

Другой вариант, который вы могли бы рассмотреть, - создать конструктор Contact, который принимает шаблонную ссылку на Particle. Это позволит Контакту добавить себя в любой реализуемый контейнер addContact(Contact).

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