OO Дизайн Циркуляр вопросов для родителей / детей?

Циклические ссылки прекрасны и абсолютно стандартны при создании древовидной структуры. HTML-модель Document Object Model (DOM), например, имеет родительские и дочерние свойства на каждом node в дереве DOM:

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

Похоже, ты на правильном пути для меня. Согласно вашей модели предметной области, у родителей есть дети, а у детей есть родители. Возможно, вам потребуется ссылаться друг на друга.

В круговых ссылках нет ничего плохого, просто нужно быть осторожным с тем, что с ними делать. Проблемы могут возникнуть при управлении вашими объектами на стороне сервера в автоматическом режиме, когда вы загружаете их из базы данных. Например, вы получаете объект Child из базы данных с помощью запроса. Вы включаете информацию о родителях? Вы включаете детей родителей?

Инструменты ORM, такие как Lightspeed или Microsoft Entity Framework, обычно справляются с этим с помощью директив «ленивой загрузки». Сначала они получат то, что вам нужно (поэтому, когда вы выбираете Child, он просто получает свойства Child и идентификатор родителя). Если позже вы разыменуете родительский объект, он получит свойства Parent и создаст экземпляр родительского объекта. Если позже вы получите доступ к его коллекции Children, она затем перейдет и извлечет соответствующую дочернюю информацию и создаст дочерние объекты для этой коллекции. Пока они вам не понадобятся, он не заполняет его.

Я считаю разумным иметь возможность перемещаться по графу объектов таким образом. Трудно понять, есть ли у вас для этого уважительная причина из вашего сообщения, но я не думаю, что ссылки сами по себе доказывают плохой дизайн.

Я верю, что вы на правильном пути. Почему у вас болит голова от кругового характера ссылок? В чем заключается основная проблема, с которой Parent ссылается на своих дочерних элементов, а Child имеет ссылку на своего родителя?

Вы говорите об иерархии классов, где родительский класс знает о своих дочерних классах?

Вам следует избегать этого любой ценой.

По умолчанию дочерний класс знает все о родительском классе, потому что он является экземпляром родительского класса. Но для того, чтобы родительский класс знал о своих дочерних классах, необходимо, чтобы дочерний класс также знал все о каждом другом дочернем классе. Это создает зависимость между одним дочерним элементом и каждым другим дочерним элементом этого класса. Это неподдерживаемый сценарий, который вызовет проблемы в будущем - если вы даже можете заставить его скомпилировать или запустить, что на многих языках не будет иметь место.

Тем не менее, мне кажется, что вы пытаетесь создать не иерархию классов, а иерархию коллекций, то есть дерево. В таком случае да, вы на правильном пути; это обычная парадигма. Родительский узел имеет набор дочерних узлов, а дочерний узел имеет ссылку на родительский узел.

Дело в том? Они одного класса! Вот очень простой пример на 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);
  }
}

Я чувствую, что это то, что тебе действительно нужно. Используя эту парадигму, вы затем подклассифицируете Node для любых гнусных целей, которые у вас могут быть.

Если я понимаю, что объекты P содержат массив объектов P-> c [], представляющих детей. И любой узел P без дочерних элементов является листом ... с каждым P, содержащим P-> P '(родительский).

Указанное вами решение с родительскими элементами, содержащими ссылки на дочерние элементы, и наоборот, устраняет необходимость перемещаться по дереву для получения предков данного дочернего элемента и дочерних элементов узла. На самом деле это просто дерево, по которому вы можете создавать всевозможные ссылки и алгоритмы для его обхода и перечисления. Что нормально!

Я предлагаю прочитать главу о деревьях в разделе Искусство компьютерного программирования, чтобы получить превосходный и глубокий взгляд на древовидные структуры и эффективные способы перечисления родителей и детей.

Если у дочерних элементов должен быть родитель, мне обычно просто требуется экземпляр родительского типа в дочернем конструкторе.

Мне кажется, вы на пути к плохому дизайну. В вашей архитектуре никогда не должно быть циклических ссылок.

Вероятно, вам следует еще раз изучить, почему вашим детям нужна обратная ссылка на родителя и наоборот. Я склоняюсь к тому, чтобы у родителей была группа детей. Затем вы можете добавить функциональность к родительскому объекту, чтобы проверить, является ли дочерний объект дочерним по отношению к экземпляру.

Лучшее объяснение цели также может быть немного более полезным ...

ИЗМЕНИТЬ

Я прочитал еще немного (и выслушал комментарии) ... и оказалось, что я совершенно не прав. Циркулярные ссылки действительно имеют свое место, если вы осторожны с ними и не позволяете им выйти из-под контроля.