Разница между Агрегацией и Ассоциацией в реализации

Question

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

Answer 1

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

Агрегация - это особая форма ассоциации с намеченным значением части-целого-отношения , где части целого могут быть разделены с другими целыми. Например, мы можем смоделировать агрегацию между классами DegreeProgram и Course, как показано на следующей диаграмме, поскольку курс является частью программы для получения степени, и курс может быть разделен между двумя или более программами для получения степени (например,Инженерная степень могла бы разделить курс по программированию на C и степень в области компьютерных наук).

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

class DegreeProgram {    
  private List<Course> courses;
  ...
}

Answer 2

Я согласен, что с точки зрения реализации и ассоциация, и агрегация выглядят одинаково - как вы упомянули, в обоих случаях один из объектов является элементом данных в другом.

Насколько я понимаю, различие в реализации , о котором вы спрашиваете, происходит не на уровне объекта, а на уровне дизайна приложения:

• Если по разнице в реализации вы понимаете сам код (способ размещения объекта внутри другого), то разницы нет.

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

Редактировать -> дополнительные пояснения добавлены ниже:

Iвозможно, не было достаточно ясно - я имел в виду, что в этом случае реализация может рассматриваться на двух уровнях:

• код, который представляет объект внутриclass (поле, содержащее ссылку на объект)

• более широкий код (как объект используется в других классах или как представлены зависимости между объектами)

Оба они могут быть поняты как реализация , но на разных уровнях абстракции - использование внутри класса одинаково для обоих Aggregation и Composition, но способ реализации объектных отношений для нескольких классов будет отличаться.

Answer 3

Если быть точным: совокупность терминов UML (вы, вероятно, имеете в виду) равна composite aggregation. В п. 110 UML 2.5 говорится:

composite - Указывает, что свойство агрегируется комплексно, т. Е. Составной объект несет ответственность за существование и хранение составных объектов (см. Определениечасти в 11.2.3).

Если вы имеете в виду общую агрегацию, см. ту же стр. 110:

shared - указывает, что свойство имеет общую семантику агрегации. Точная семантика разделяемой агрегации зависит от области применения и модели.

---

tl; dr

Разница довольно проста. Составной (агрегатный) объект должен быть уничтожен, если агрегатирующий объект прощается. Связанный объект не заботится (или ссылающийся объект не будет пытаться уничтожить его).

Для общей агрегации: придумайте собственное определение и опубликуйте его вместе с его использованием.