C ++ kodumda sınıf bağımlılığı nasıl giderilir?

C ++ projemde iki sınıfım var Particleve Contact. Olarak Particlesınıf, bir üye değişkeni olan std::vector<Contact> contactsbir bütün temas içeren Particlebir nesne ve karşılık gelen üye işlevlerini getContacts()ve addContact(Contact cont). Bu nedenle, "Particle.h" içinde, "Contact.h" yi içerir.

In Contactsınıfında, ben kurucusuna kodu eklemek istiyorum Contacto arayacak Particle::addContact(Contact cont)böylece contactsher ikisi için güncellenir Particlehangi arasındaki nesneler Contactnesne ekleniyor. Bu nedenle, "Contact.cpp" içine "Particle.h" eklemem gerekir.

Benim sorum, bunun kabul edilebilir / iyi kodlama uygulaması olup olmadığıdır ve eğer değilse, elde etmeye çalıştığım şeyi uygulamak için daha iyi bir yol ne olacaktır (basitçe, yeni bir kişi olduğunda belirli bir parçacık için kişi listesini otomatik olarak güncelleme yaratıldı).

Bu sınıflar, NetworkN parçacıkları ( std::vector<Particle> particles) ve Nc kontakları ( std::vector<Contact> contacts) olacak bir sınıf tarafından birbirine bağlanır . Ama ben particles[0].getContacts()bu gibi Particlesınıfta böyle fonksiyonlara sahip olmak için iyi mi , ya da bu durumda C ++ daha iyi bir ilişki "yapısı" var mı istedim (başka bir sınıfta kullanılan ilgili iki sınıf) .

Burada buna nasıl yaklaştığım konusunda bir perspektif değişikliğine ihtiyacım olabilir. İki sınıf bir Networksınıf nesnesi tarafından bağlandığından , bağlantı bilgilerinin tamamen Networknesne tarafından kontrol edilmesi tipik bir kod / sınıf organizasyonu mudur (bir Particle nesnesinin temaslarının farkında olmaması ve dolayısıyla bir getContacts()üyesi olmaması gerekir) fonksiyonu). Daha sonra, belirli bir parçacığın hangi temas noktalarına sahip olduğunu bilmek için, bu bilgiyi Networknesne aracılığıyla elde etmem gerekir (örn network.getContacts(Particle particle). Kullanarak ).

Bir Parçacık nesnesinin bu bilgiye sahip olması daha az tipik (belki de cesareti kırılmış) C ++ sınıf tasarımının da (yani, bilgiye ne olursa olsun - Ağ nesnesi veya Parçacık nesnesi aracılığıyla - hangisi daha uygun görünüyorsa) )?

Sorunuzda iki bölüm var.

İlk bölüm C ++ başlık dosyalarının ve kaynak dosyalarının organizasyonudur. Bu, ileri bildirimi ve sınıf bildiriminin (başlık dosyasına yerleştirilmesi) ve yöntem gövdesinin (kaynak dosyaya yerleştirilmesi) ayrılması kullanılarak çözülür . Ayrıca, bazı durumlarda daha zor vakaları çözmek için Pimpl deyimini ("uygulamaya işaretçi") uygulayabiliriz . En iyi uygulamalara göre, paylaşılan sahiplik işaretçileri ( shared_ptr), tek sahiplik işaretçileri ( unique_ptr) ve sahip olmayan işaretçiler (ham işaretçi, yani "yıldız işareti") kullanın.

İkinci bölüm, bir grafik şeklinde birbiriyle ilişkili nesnelerin nasıl modelleneceğidir . DAG olmayan genel grafiklerin (yönlendirilmiş asiklik grafikler), ağaç benzeri sahipliği ifade etmenin doğal bir yolu yoktur. Bunun yerine, düğümlerin ve bağlantıların tümü tek bir grafik nesnesine ait olan meta verilerdir. Bu durumda, düğüm-bağlantı ilişkisini toplama olarak modellemek mümkün değildir. Düğümler "kendi" bağlantılarına sahip değildir; bağlantılar "kendi" düğümlerine sahip değildir. Bunun yerine, ilişkilendirmelerdir ve hem düğümler hem de bağlantılar grafiğe "aittir". Grafik, düğümler ve bağlantılar üzerinde çalışan sorgulama ve düzenleme yöntemleri sağlar.

Eğer seni haklıyorsam, aynı temas nesnesi birden fazla parçacık nesnesine aittir, çünkü iki veya daha fazla parçacık arasındaki bir tür fiziksel teması temsil eder, değil mi?

Şüpheli olduğunu düşündüğüm ilk şey neden Particlebir üye değişkene sahip std::vector<Contact>? Bunun yerine bir std::vector<Contact*>veya bir olmalıdır std::vector<std::shared_ptr<Contact> >. veya bunun addContactgibi farklı imzalara sahip olmalıdır .addContact(Contact *cont)addContact(std::shared_ptr<Contact> cont)

Bu, "Particle.h" içine "Contact.h" ifadesini eklemeyi gereksiz kılar, "Particle.h" içinde ileri bir bildirim ve class Contact"Particle.cpp" içinde "Contact.h" ifadesini eklemek yeterli olacaktır.

Sonra kurucu hakkında soru. Gibi bir şey istiyorsun

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

Sağ? Bu tasarım, programınız bir temas nesnesinin oluşturulması gereken zamanda her zaman ilgili parçacıkları bildiği sürece tamamdır.

std::vector<Contact*>Rotaya giderseniz , Contactnesnelerin ömrü ve mülkiyeti hakkında bazı düşünceler yatırmanız gerekir . Hiçbir parçacık kendi kişilerine "sahip değildir", bir kişinin yalnızca ilgili iki Particlenesne de yok edildiğinde silinmesi gerekecektir . Kullanılması std::shared_ptr<Contact>sizin için otomatik olarak bu sorunu çözecektir yerine. Ya da bir "çevreleyen bağlam" nesnesinin parçacıkların ve temasların (@rwong tarafından önerildiği gibi) sahipliğini almasına ve ömürlerini yönetmesine izin vermiş olursunuz.

Evet, açıkladığınız şey, her Contactörneğin bir a'nın kişiler listesinde olmasını sağlamak için kabul edilebilir bir yoldur Particle.

Yaptığınız doğru.

Başka bir yol ... Amaç, her Contactşeyin bir listede olmasını sağlamaksa , şunları yapabilirsiniz:

• Contact(özel inşaatçılar) oluşturulmasını engelle ,
• ileri deklare Particlesınıfı,
• yapmak Particlesınıf arkadaşı Contact,
• içinde Particlea oluşturan bir fabrika yöntemini oluşturmakContact

Sonra dahil etmek gerekmez particle.hiçindecontact

Düşünebileceğiniz başka bir seçenek de, bir Particle referansını kabul eden Contact yapıcısını şablon haline getirmektir. Bu, bir Kişinin kendisini uygulayan herhangi bir kaba eklemesine izin verecektir addContact(Contact).

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