OO design pergunta - pai / filho (s) - Circular?

StackOverflow https://stackoverflow.com/questions/1028965

Pergunta

Eu sou bastante novo para o processo de design OO, por isso, tenha comigo ....

Eu tenho duas entidades que preciso para modelar as classes, chamá-los de pai e filho (é perto o suficiente para o domínio do problema real). Família monoparental terá um ou mais filhos -. Eu não tenho interesse, nesta aplicação, no pais sem filhos

Onde o meu cérebro está saindo para o almoço é no fato de que eu preciso ser capaz de encontrar a partir do outro. No meu banco de dados que posso implementar isso com uma relação de chave estrangeira normal, ea natureza baseada em conjunto de SQL faz com que seja fácil encontrar todas as crianças para um determinado Pai, ou o pai para um determinado Criança. Mas como objetos ...?

I pensar que o pai deve levar uma coleção (lista, qualquer que seja) de crianças. Eu também acho que cada criança deve levar uma referência ao seu pai. A natureza circular das referências, no entanto, está fazendo minha cabeça doer.

Am I:

  • No caminho certo?
  • completamente erradas? Se assim for, o que devo fazer de diferente?

Isto irá quase certamente ser implementado em VB.NET, mas eu sou um maneiras de cortar código ainda.

Editar após 8 respostas:

Obrigado a todos. Foi difícil escolher apenas uma resposta a aceitar.

Para esclarecer um par de coisas que foram questionados nas respostas:

  • pai e filho são muito diferentes entidades - não há herança relação a todos. Eu escolhi o nomes que eu fiz, porque eles são realmente muito perto do mundo real domínio do problema, e agora vejo que é uma fonte de confusão de uma OO perspectiva.
  • A hierarquia é apenas um nível profundo - As crianças nunca terá Crianças dentro do aplicativo.

Obrigado novamente.

Foi útil?

Solução

As referências circulares são muito bem e absolutamente padrão ao criar uma estrutura de árvore. Document Object Model do HTML (DOM), por exemplo, tem as propriedades pai e filho em cada nó em uma árvore DOM: 

interface Node {
    // ...
    readonly attribute Node     parentNode;
    readonly attribute NodeList childNodes;
    // ...
}

Outras dicas

Parece que você está no caminho certo para mim. Como por seu modelo de domínio, os pais têm filhos e os filhos têm pais. Você pode precisar fazer referência a cada um dos outros.

Não há nada de errado com referências circulares, você apenas tem que ter cuidado sobre o que fazer com eles. Onde você vai correr em problemas está a gerir as suas entidades no lado do servidor de forma automatizada quando você carregá-los a partir do banco de dados. Por exemplo, você buscar um objeto filho do banco de dados com uma consulta. Você incluir as informações do pai? Você incluir as crianças dos pais?

ferramentas ORM como Lightspeed ou Entity Framework da Microsoft geralmente lidar com isso usando directivas "carregamento lento". Eles vão buscar o que você precisa em primeiro lugar (por isso, quando você buscar uma criança, ele só obtém as propriedades da Criança e ID do pai). Se, mais tarde, você excluir a referência o pai, ele vai e obtém as propriedades do pai e instancia o objeto pai. Se mais tarde ainda, você acessá-lo da coleção Crianças, em seguida, vai e vai buscar a informação da criança relevantes e cria objetos filho para essa coleção. Até que você precisa deles, porém, não preenchê-lo.

Eu acho que é razoável querer ser capaz de atravessar o gráfico do objeto desta forma. É difícil saber se você tem uma razão justificável para ele a partir do seu post, mas eu não acho que as referências em si provar um design ruim.

Eu acredito que você está no caminho certo. Por que é a natureza circular das referências que fazem a sua cabeça doer? Qual é a questão fundamental que você está tendo com um Parent ter referências a seus filhos, e um Child ter uma referência ao seu pai?

Você está falando de uma hierarquia de classes, onde a classe pai sabe sobre suas classes filhas?

Você deve evitar a todo o custo.

Por padrão, uma classe criança sabe tudo sobre uma classe pai, , pois é uma instância da classe pai . Mas para ter uma classe conhecimento dos pais sobre suas classes criança requer que a classe criança também sabe tudo sobre todas as outras classes filho. Isso cria uma dependência entre uma criança e qualquer outra criança da classe. Este é um cenário insustentável que irá causar problemas no futuro - se você ainda pode obtê-lo para compilar ou correr, o que em muitos idiomas não será o caso.

Dito isto, parece-me que você não está tentando fazer uma hierarquia de classes, mas a hierarquia do conjunto, ou seja, uma árvore. Nesse caso, sim, você está no caminho certo; é um paradigma comum. O nó pai tem uma coleção de nós filho, e o nó filho tem uma referência para o nó pai.

A coisa é? Eles são todos da mesma classe ! Aqui está um exemplo muito simples em C #: 

public class Node
{
  public readonly Node Parent; // null Parent indicates root node
  public readonly List<Node> Children = new List<Node>();
  public Node(Node parent)
  {
     Parent = parent;
  }
  public Node()
  {
     parent = null;
  }
  public void AddChild(Node node)
  {
     Children.Add(node);
  }
}

Eu tenho um sentimento que este é o que você está realmente depois. Utilizando este paradigma, você iria em seguida, sub-classe Node para quaisquer fins nefasto que você pode ter.

Se eu entender que objetos de P contêm uma matriz de objetos P-> c [] representando crianças. E qualquer nó P sem filhos é uma folha ... com cada P contendo P-> P'(o pai).

A solução que você especificar, com Pais contendo referências a crianças e vice-versa elimina a necessidade de percorrer a árvore para obter ascendência de uma determinada criança e as crianças de um nó. Isto é realmente apenas uma árvore que você pode realizar todos os tipos de links e algoritmos para travessia e enumerá-lo. O que é bom!

Eu sugiro a leitura do capítulo árvores em The Art of Computer Programming para uma excelente e em profundidade olhar para estruturas de árvore e maneiras eficientes para enumerar parentesco e crianças.

Se as crianças deve tem um pai que eu normalmente requerem apenas uma instância de tipo pai no construtor criança.

Parece-me que você está no caminho para um design ruim. Sua arquitetura nunca deve ter referências circulares.

Você provavelmente deve re-examinar por que seus filhos precisam de uma volta de referência para o pai e vice-versa. Eu inclinar-se para a mãe com uma coleção de crianças. Você pode então adicionar funcionalidade para o pai para verificar se um objeto filho é um filho da ocorrência.

A melhor explination da meta poderia ser um pouco mais útil, bem como ...

Editar

Eu li um pouco mais (e ouviu comentários) ... e não é que eu sou muito errado. referências circulares que, de fato, têm o seu lugar, enquanto você tiver cuidado com eles e não deixá-los sair da mão.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top