Como resolver a interdependência de classe no meu código C ++?

No meu projeto C ++, tenho duas classes Particlee Contact. Na Particleclasse, eu tenho uma variável de membro std::vector<Contact> contactsque contém todos os contatos de um Particleobjeto e as funções de membro correspondentes getContacts()e addContact(Contact cont). Assim, em "Particle.h", incluo "Contact.h".

Na Contactclasse, eu gostaria de adicionar código ao construtor para o Contactque será chamado Particle::addContact(Contact cont), para que contactsseja atualizado para os dois Particleobjetos entre os quais o Contactobjeto está sendo adicionado. Assim, eu teria que incluir "Particle.h" em "Contact.cpp".

Minha pergunta é se isso é aceitável / uma boa prática de codificação e, se não, qual seria a melhor maneira de implementar o que estou tentando alcançar (basta colocar, atualizar automaticamente a lista de contatos de uma partícula específica sempre que um novo contato é criado).

Essas classes serão ligadas por uma Networkclasse que terá N partículas ( std::vector<Particle> particles) e contatos Nc ( std::vector<Contact> contacts). Mas eu queria poder ter funções como particles[0].getContacts()- é aceitável ter essas funções na Particleclasse nesse caso, ou existe uma "estrutura" de associação melhor em C ++ para esse propósito (duas classes relacionadas sendo usadas em outra classe) .

Talvez eu precise de uma mudança de perspectiva aqui na maneira como estou abordando isso. Como as duas classes são conectadas por um Networkobjeto de classe, é típico da organização de código / classe ter informações de conectividade totalmente controladas pelo Networkobjeto (em que um objeto Particle não deve estar ciente de seus contatos e, consequentemente, não deve ter um getContacts()membro função). Então, para saber quais contatos uma partícula específica possui, eu precisaria obter essas informações através do Networkobjeto (por exemplo, usando network.getContacts(Particle particle)).

Seria menos típico (talvez até desanimado) o design da classe C ++ para um objeto Particle ter esse conhecimento também (por exemplo, ter várias maneiras de acessar essas informações - por meio do objeto Rede ou do objeto Particle, o que parecer mais conveniente )?

Há duas partes na sua pergunta.

A primeira parte é a organização dos arquivos de cabeçalho e arquivos de origem C ++. Isso é resolvido usando a declaração direta e a separação da declaração da classe (colocando-as no arquivo de cabeçalho) e o corpo do método (colocando-as no arquivo de origem). Além disso, em alguns casos, pode-se aplicar o idioma Pimpl ("ponteiro para implementação") para resolver casos mais difíceis. Use ponteiros de propriedade compartilhada ( shared_ptr), ponteiros de propriedade única ( unique_ptr) e ponteiros não proprietários (ponteiro bruto, ou seja, o "asterisco") de acordo com as práticas recomendadas.

A segunda parte é como modelar objetos inter-relacionados na forma de um gráfico . Gráficos gerais que não são DAGs (gráficos acíclicos direcionados) não têm uma maneira natural de expressar a propriedade de uma árvore. Em vez disso, os nós e as conexões são todos os metadados que pertencem a um único objeto gráfico. Nesse caso, não é possível modelar o relacionamento de conexão do nó como agregações. Nós não "possuem" conexões; conexões não "possuem" nós. Em vez disso, são associações e os nós e as conexões são "de propriedade" do gráfico. O gráfico fornece métodos de consulta e manipulação que operam nos nós e nas conexões.

Se eu entendi direito, o mesmo objeto de contato pertence a mais de um objeto de partícula, pois representa algum tipo de contato físico entre duas ou mais partículas, certo?

Então a primeira coisa que acho questionável é por Particleque uma variável membro std::vector<Contact>? Deve ser um std::vector<Contact*>ou um em std::vector<std::shared_ptr<Contact> >vez disso. addContactentão deve ter assinatura diferente como addContact(Contact *cont)ou addContact(std::shared_ptr<Contact> cont)não.

Isso torna desnecessário incluir "Contact.h" em "Particle.h", uma declaração direta de class Contact"Particle.h" e uma inclusão de "Contact.h" em "Particle.cpp" será suficiente.

Então a pergunta sobre o construtor. Você quer algo como

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

Direita? Esse design é bom, desde que o seu programa sempre saiba as partículas relacionadas no momento em que um objeto de contato deve ser criado.

Observe que, se você seguir o std::vector<Contact*>caminho, precisará investir alguns pensamentos sobre a vida útil e a propriedade dos Contactobjetos. Nenhuma partícula "possui" seus contatos, um contato provavelmente terá que ser excluído apenas se os dois Particleobjetos relacionados forem destruídos. Usar em std::shared_ptr<Contact>vez disso resolverá esse problema automaticamente para você. Ou você deixa um objeto de "contexto circundante" assumir a propriedade de partículas e contatos (como sugerido por @rwong) e gerenciar sua vida útil.

Sim, o que você descreve é ​​uma maneira muito aceitável de garantir que cada Contactinstância esteja na lista de contatos de a Particle.

O que você fez está correto.

Outra maneira ... Se o objetivo é garantir que todos Contactestejam em uma lista, você pode:

• bloquear a criação de Contact(construtores privados),
• declarar Particleclasse a frente ,
• faça da Particleclasse um amigo Contact,
• em Particlecriar um método de fábrica que cria umContact

Então você não tem que incluir particle.hnacontact

Outra opção que você pode considerar é criar o construtor Contact que aceita um modelo de referência de Partícula. Isso permitirá que um contato se adicione a qualquer contêiner implementado addContact(Contact).

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