Есть ли какие-либо шаблоны или существует какая-либо стандартная терминология для наследования данных/объектов?

Question

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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