Як вирішити взаємозалежність класу в моєму коді 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об'єктом (у тому, що об'єкт Частинки не повинен знати про свої контакти, а отже, він не повинен мати getContacts()члена функція). Потім, щоб знати, які контакти має конкретна частинка, мені потрібно було б отримати цю інформацію через Networkоб'єкт (наприклад, за допомогою network.getContacts(Particle particle)).

Чи було б менш типовим (можливо, навіть відстороненим) дизайном класу C ++ для об’єкта 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екземпляр знаходиться у списку контактів Particle.

Те, що ви зробили, правильно.

Інший спосіб ... Якщо мета - переконатися, що кожен Contactє у списку, то ви можете:

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

Тоді не потрібно включати particle.hвcontact

Інший варіант, який ви можете розглянути, - це зробити конструктор Contact, який приймає посилання на частинку. Це дозволить Контакту додати себе до будь-якого контейнера, який реалізується addContact(Contact).

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