Существуют ли какие-либо шаблоны или стандартная терминология для наследования данных / объектов? - PullRequest
3 голосов
/ 10 января 2010

У меня есть класс A, в котором есть коллекция объектов класса B. Класс A также может «наследовать» (из-за отсутствия лучшего термина) коллекцию объектов класса B от других экземпляров класса A. Для моделирования этого экземпляры класса A указывают на другие экземпляры класса A (я контролирую циклические ссылки). ).

Упрощенным конкретным примером может быть то, что у человека есть биологические дети, но он также "наследует" детей от своего супруга и бывших супругов.

Я использую экземпляры класса A с и без унаследованных объектов в моем приложении во время выполнения. То есть обе «проекции» экземпляров класса A имеют значение для меня в контексте моего применения в разностных сценариях.

Мой вопрос: есть ли шаблон для кодирования такого рода модели или стандартной терминологии? Я не думаю, что слово «наследовать» здесь подходит. У меня есть свои собственные способы справиться с этим технически и моя громоздкая терминология, но я воображаю, что есть стандартный шаблон, которого я могу придерживаться, которого я просто не могу найти.

Несовершенным аналогом будет проверка методов классов .NET с унаследованными методами и без них или проверка прототипов в Javascript, но здесь я «наследую» записи / объекты.

Ответы [ 4 ]

2 голосов
/ 10 января 2010

Для меня это выглядит как составной шаблон с объектами A, являющимися композитами, и листьями B. Один объект A, который указывает на другие объекты A, является корневым элементом. Разница, по-видимому, заключается в том, что при получении листовых элементов вы различаете, включает ли корневой элемент листовые элементы из других известных ему композитов.

1 голос
/ 10 января 2010

Нет, я не думаю, что (A) есть общие идиомы ООП для того, что вы делаете, и (B) какие-либо выдающиеся паттерны, подобные вашим. И (C), это абсолютно нормально . Теперь, может быть, вы должны делать это таким образом, а может быть, вам не следует. Всякий раз, когда вы делаете что-то, что вам трудно описать, вы, конечно, должны сами догадаться и задуматься, есть ли более простой способ сделать это. Но отсутствие общей терминологии для описания вашей модели и отсутствие ее соответствия «шаблону», о котором вы слышали, само по себе не указывает на проблему . Занятиям иногда приходится делать дурацкие вещи под капотом. В этом-то и дело. Если вы инкапсулируете много сложностей для потребителей этих классов, и они интуитивно понятны, логичны и открыты для них, тогда отлично!

Это ошибка, если неправильно использовать общие термины, чтобы попытаться помочь кому-то понять. На самом деле, использование вами термина наследовать выше действительно смутило меня, и я до сих пор не уверен на 100%, что он у меня есть. Это так?

Объект класса ClassA поддерживает коллекцию объектов ClassB. Кроме того, некоторые функциональные возможности объекта ClassA должны воздействовать не только на его собственные объекты ClassB, но и на те, которые поддерживаются другими объектами ClassA. С этой целью объект ClassA поддерживает ссылки на другие объекты ClassA.

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

0 голосов
/ 10 января 2010

ООП определяет два основных типа отношений:

  1. A является B
  2. A имеет B

В рамках второй категории у вас есть подкатегории:

  • A содержит B
  • B является компонентом A
  • A связано с (или ссылками ) B

Первые два похожи, но ваш конкретный пример явно относится к третьему. Родители не содержат детей, они связаны со своими детьми, и когда кто-то вступает в брак, у него появляются новые отношения (ассоциации) с существующей семьей.

Так что я думаю, что ответ "нет", здесь нет "шаблона". Вы просто копируете / трансформируете набор отношений из одного экземпляра в другой.

0 голосов
/ 10 января 2010

Я думаю, что ваша модель виновата. Если два или более экземпляра класса имеют отношение с экземпляром другого класса, правильная модель не должна сделать один из экземпляров , содержащий третьим - это заставить оба из них ссылаться к третьему. В случае родителей-людей каждый должен ссылаться на один и тот же объект «потомство» (список детей). Затем вы управляете упомянутым классом с помощью таких механизмов, как подсчет ссылок.

...