Вопрос о Дизайне OO — Родитель/Ребенок (ren) — Проспект?

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

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

Инструменты ORM, такие как Lightspeed или Microsoft Entity Framework, обычно справляются с этим с помощью директив «отложенной загрузки». Сначала они получат то, что вам нужно (поэтому, когда вы выбираете Child, он просто получает свойства Child, а родительский s ID). Если позже вы разыменовываете родительский объект, он выбирает родительские свойства и создает экземпляр родительского объекта. Если еще позже вы получите доступ к его коллекции 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 '(родительский).

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

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

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

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

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

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

EDIT

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