Làm thế nào để giải quyết sự phụ thuộc lẫn nhau trong mã C ++ của tôi?

Trong dự án C ++ của tôi, tôi có hai lớp Particlevà Contact. Trong Particlelớp, tôi có một biến thành viên std::vector<Contact> contactschứa tất cả các liên hệ của một Particleđối tượng và các hàm thành viên tương ứng getContacts()và addContact(Contact cont). Do đó, trong "Particle.h", tôi bao gồm "Contact.h".

Trong Contactlớp, tôi muốn thêm mã vào hàm tạo cho lệnh Contactđó sẽ gọi Particle::addContact(Contact cont), để nó contactsđược cập nhật cho cả các Particleđối tượng mà Contactđối tượng đang được thêm vào. Vì vậy, tôi sẽ phải đưa "Particle.h" vào "Contact.cpp".

Câu hỏi của tôi là liệu điều này có được chấp nhận / thực hành mã hóa tốt hay không và nếu không, cách nào tốt hơn để thực hiện những gì tôi đang cố gắng đạt được (chỉ cần đặt, tự động cập nhật danh sách các liên hệ cho một hạt cụ thể bất cứ khi nào có liên hệ mới được tạo ra).

Các lớp này sẽ được liên kết với nhau bởi một Networklớp sẽ có các hạt N ( std::vector<Particle> particles) và Nc contact ( std::vector<Contact> contacts). Nhưng tôi muốn có thể có các hàm như particles[0].getContacts()- có ổn không khi có các hàm như vậy trong Particlelớp trong trường hợp này, hoặc có một "cấu trúc" liên kết tốt hơn trong C ++ cho mục đích này (của hai lớp liên quan được sử dụng trong lớp khác) .

Tôi có thể cần một sự thay đổi quan điểm ở đây trong cách tôi đang tiếp cận điều này. Do hai lớp được kết nối bởi một Networkđối tượng lớp, nên tổ chức mã / lớp điển hình có thông tin kết nối được kiểm soát hoàn toàn bởi Networkđối tượng (trong đó một đối tượng Hạt không nên biết về các liên hệ của nó và do đó, nó không nên có getContacts()thành viên chức năng). Sau đó, để biết những liên hệ nào mà một hạt cụ thể có, tôi sẽ cần lấy thông tin đó thông qua Networkđối tượng (ví dụ: sử dụng network.getContacts(Particle particle)).

Nó sẽ ít điển hình hơn (thậm chí có thể không khuyến khích) thiết kế lớp C ++ cho một đối tượng Hạt để có kiến ​​thức đó, (có nghĩa là có nhiều cách để truy cập thông tin đó - thông qua đối tượng Mạng hoặc đối tượng Hạt, có vẻ thuận tiện hơn )?

Có hai phần trong câu hỏi của bạn.

Phần đầu tiên là tổ chức các tệp tiêu đề C ++ và các tệp nguồn. Điều này được giải quyết bằng cách sử dụng khai báo chuyển tiếp và tách khai báo lớp (đặt chúng vào tệp tiêu đề) và thân phương thức (đặt chúng vào tệp nguồn). Hơn nữa, trong một số trường hợp, người ta có thể áp dụng thành ngữ Pimpl ("con trỏ để thực hiện") để giải quyết các trường hợp khó hơn. Sử dụng con trỏ sở hữu chung ( shared_ptr), con trỏ sở hữu đơn ( unique_ptr) và con trỏ không sở hữu (con trỏ thô, tức là "dấu hoa thị") theo thông lệ tốt nhất.

Phần thứ hai là làm thế nào để mô hình hóa các đối tượng có liên quan đến nhau dưới dạng biểu đồ . Các biểu đồ chung không phải là DAG (biểu đồ chu kỳ có hướng) không có cách thể hiện quyền sở hữu giống như cây. Thay vào đó, các nút và kết nối đều là siêu dữ liệu thuộc về một đối tượng đồ thị. Trong trường hợp này, không thể mô hình hóa mối quan hệ kết nối nút dưới dạng tập hợp. Các nút không "kết nối" riêng; các kết nối không "nút" riêng. Thay vào đó, chúng là các hiệp hội và cả các nút và kết nối được "sở hữu" bởi biểu đồ. Biểu đồ cung cấp các phương thức truy vấn và thao tác hoạt động trên các nút và kết nối.

Nếu tôi hiểu bạn đúng, cùng một đối tượng tiếp xúc thuộc về nhiều hơn một đối tượng hạt, vì nó đại diện cho một loại tiếp xúc vật lý giữa hai hoặc nhiều hạt, phải không?

Vì vậy, điều đầu tiên mà tôi nghĩ là nghi vấn là tại sao Particlecó một biến thành viên std::vector<Contact>? Nó nên là một std::vector<Contact*>hoặc std::vector<std::shared_ptr<Contact> >thay thế. addContactsau đó nên có chữ ký khác nhau như addContact(Contact *cont)hoặc addContact(std::shared_ptr<Contact> cont)thay vào đó.

Điều này khiến không cần thiết phải bao gồm "Contact.h" trong "Particle.h", một tuyên bố chuyển tiếp class Contacttrong "Particle.h" và bao gồm "Contact.h" trong "Particle.cpp" là đủ.

Sau đó, câu hỏi về các nhà xây dựng. Bạn muốn một cái gì đó như

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

Đúng? Thiết kế này là ổn, miễn là chương trình của bạn luôn biết các hạt liên quan tại thời điểm khi một đối tượng tiếp xúc phải được tạo.

Lưu ý, nếu bạn đi theo std::vector<Contact*>lộ trình, bạn phải đầu tư một số suy nghĩ về tuổi thọ và quyền sở hữu của các Contactđối tượng. Không có hạt nào "sở hữu" các liên hệ của nó, một liên hệ có thể sẽ phải bị xóa chỉ khi cả hai Particleđối tượng liên quan bị phá hủy. Sử dụng std::shared_ptr<Contact>thay thế sẽ giải quyết vấn đề này cho bạn tự động. Hoặc bạn để một đối tượng "bối cảnh xung quanh" nắm quyền sở hữu các hạt và địa chỉ liên hệ (như được đề xuất bởi @rwong) và quản lý vòng đời của chúng.

Có, những gì bạn mô tả là một cách rất chấp nhận để đảm bảo rằng mọi Contacttrường hợp đều nằm trong danh sách liên hệ của a Particle.

Những gì bạn đã làm là chính xác.

Một cách khác ... Nếu mục đích là để đảm bảo rằng mọi thứ đều Contactnằm trong danh sách, thì bạn có thể:

• tạo khối Contact(nhà xây dựng riêng),
• chuyển tiếp khai báo Particlelớp,
• làm cho Particlelớp một người bạn của Contact,
• trong việc Particletạo ra một phương thức nhà máy tạo ra mộtContact

Sau đó, bạn không cần phải bao gồm particle.htrongcontact

Một tùy chọn khác mà bạn có thể xem xét là làm cho hàm tạo Liên hệ chấp nhận tham chiếu Hạt tham chiếu. Điều này sẽ cho phép một Liên hệ tự thêm vào bất kỳ vùng chứa nào addContact(Contact).

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