Агрегация против состава [закрыто]

Как правило:

class Person {
    private Heart heart;
    private List<Hand> hands;
}

class City {
    private List<Tree> trees;
    private List<Car> cars
}

в состав (человек, сердце, рука)," подобъекты " (сердце, рука) будут уничтожены, как только человек будет уничтожен.

В наборе (город, дерево, автомобиль) "подобъекты" (дерево, автомобиль) не будут уничтожены, когда город будет уничтожен.

суть в том, что композиция подчеркивает взаимное существование, и в агрегации это свойство не требуется.

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

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

агрегация: объект существует вне других, создается снаружи, поэтому он передается в качестве аргумента (например) в construtor. Пример: люди-автомобиль. Автомобиль создан в другом контексте, а затем становится человеком свойство.

// code example for Aggregation:
// reference existing HttpListener and RequestProcessor
public class WebServer {
  private HttpListener listener;
  private RequestProcessor processor;
  public WebServer(HttpListener listener, RequestProcessor processor) {
    this.listener = listener;
    this.processor = processor;
  }
}

состав: объект существует, или имеет смысл только внутри другой, а часть другие. Пример: люди-сердце. Вы не создаете сердце, а затем передаете его человеку.

// code example for composition:
// create own HttpListener and RequestProcessor
public class WebServer {
  private HttpListener listener;
  private RequestProcessor processor;
  public WebServer() {
    this.listener = new HttpListener(80);
    this.processor = new RequestProcessor(“/www/root”);
  }
}

объяснил, Вот пример разница между агрегацией и композицией

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

значение здесь, с точки зрения дизайна, часто связано с продолжительностью жизни объекта, как сказал другой плакат. Скажем, у вас есть клиент, и у них есть учетная запись. Эта учетная запись является "составленным" объектом клиента (по крайней мере, в большинстве контексты, о которых я могу думать). Если вы удалите клиента, учетная запись не имеет значения сама по себе, поэтому она также будет удалена. Обратное часто верно при создании объекта. Поскольку учетная запись имеет значение только в контексте клиента, создание учетной записи будет происходить как часть создания клиента (или, если вы делаете это лениво, это будет частью некоторой транзакции клиента).

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

Как в коде, это часто трудно сказать. Почти все в коде является ссылкой на объект, поэтому может быть не очевидно, является ли указанный объект составленным (принадлежащим) или агрегированным.

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

в документе спецификации UML определение термина " композиция "всегда подразумевало неразделяемые части, но не было ясно, что является определяющей характеристикой" композиции", а что просто необязательной характеристикой. Даже в новая версия (по состоянию на 2015 год), UML 2.5, после попытки улучшить определение термина "композиция", она по-прежнему остается двусмысленной и не дает никаких указаний о том, как моделировать части-целые-ассоциации с неразделяемыми частями, где части могут быть отделены и пережить разрушение целого, в отличие от случая, когда части не могут быть отделены и уничтожены вместе с целым. Они говорят:

если составной объект удален, то все его экземпляры деталей, которые являются объектами, удаляются вместе с ним.

но в то же время они же говорят

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

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

1) Состав

как Мартин Фаулер объяснил, основной вопрос для характеристики композиции заключается в том, что " объект может быть только частью одной композиции отношение." Это также объясняется в отличном блогеUML композиция против агрегации против ассоциации Герт Беллекенс. В дополнение к этой определяющей характеристике композиции (иметь эксклюзивные или не-shareable, части), композиция может также иметь зависимость жизненного цикла между композитом и его компонентами. На самом деле, есть два вида таких зависимости:

1. всякий раз, когда компонент всегда должны быть прикреплены к композиту, или, другими словами, когда он имеет обязательной составной, как выражается" точно одна " кратность на составной стороне линии композиции, тогда она должна либо повторно использоваться (или повторно присоединяться) к другому композиту, либо разрушаться, когда его текущий композит разрушается. Это иллюстрируется композицией между Personи Heart, показано на схеме ниже. Сердце либо разрушается, либо пересаживается другому человеку, когда его владелец умер.
2. всякий раз, когда компонент не может быть отдельно стоящее из его композита, или, другими словами, когда он мотыльки, тогда и только тогда, компонент должен быть уничтожен, когда его составного разрушается. Пример такой композиции-неотъемлемая часть композиции между Personи Brain.

спецификация UML гласит: "часть может быть удалена из составного экземпляра до удаления составного экземпляра и, таким образом, не будет удалена как часть составного экземпляра."В Примере a Car -Engine состав, как показано в следуя схеме, ясно, что двигатель может быть отсоединен от автомобиля до того, как автомобиль будет уничтожен, и в этом случае двигатель не будет уничтожен и может быть повторно использован. Это подразумевается ноль или один кратность на составной стороне линии композиции.

The кратность конца ассоциации композиции на составной стороне либо 1, либо 0..1, в зависимости от дело в том, если компоненты имеют обязательный композит (должны быть прикреплены к композиту) или нет. Если компоненты мотыльки, это означает, что они имеют обязательной составной.

2) агрегирование

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

однако понятие агрегации с разделяемых частей на самом деле это не так много значит, поэтому он не имеет никаких последствий для реализации, и поэтому многие разработчики предпочитайте не использовать белый алмаз в своих диаграммах классов, а просто моделировать простую ассоциацию. Спецификация UML говорит:"точная семантика общей агрегации зависит от области приложения и модельера".

The кратность конца ассоциации агрегации на всей стороне может быть любое число ( * ), потому что часть может принадлежать, или shared среди, любое количество целых.

в терминах кода composition обычно предполагает, что содержащий объект отвечает за создание экземпляров компонента*, а содержащий объект содержит только длительные ссылки на него. Поэтому, если родительский объект будет удален и собран мусор, то и ребенок будет.

Так этот код...

Class Order
   private Collection<LineItem> items;
   ...
   void addOrderLine(Item sku, int quantity){
         items.add(new LineItem(sku, quantity));
   }
}

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

* n. b. контейнер ответственность например, компонент, но он может фактически не вызывать new...() сам по себе-это java, обычно есть фабрика или две, чтобы пройти сначала!

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

Я получил некоторый пробег из UML для генерации кода, для исходного кода или DDL для реляционной базы данных. Там я использовал композицию, чтобы указать, что таблица имеет ненулевой внешний ключ (в базе данных) и ненулевой "Родительский" (и часто "окончательный") объект в моем коде. Я использую агрегацию, где я намереваюсь запись или объект, чтобы иметь возможность существует как "сирота", не привязанный ни к одному родительскому объекту или" принятый " другим родительским объектом.

пример, который мне нравится: состав: Вода-это часть - пруд. (Пруд-это состав воды.) агрегация: Пруд и утки и рыбы (прудовые агрегаты уток и рыб)

Как вы можете видеть, я выделил жирным шрифтом "часть" и "имеет", поскольку эти 2 фразы обычно могут указывать на то, какая связь существует между классами.

но, как указывали другие, много раз, является ли соединение a композиция или агрегация зависит от приложения.

Это так трудно сделать разницу между совокупным отношением и составным отношением, но я собираюсь взять несколько примеров, У нас есть дом и комнаты, здесь у нас есть сложное отношение, комната-это часть дома , и жизнь комнаты началась с жизни дома и закончится, когда закончится жизнь дома, комната-это часть дома, мы говорим о композиции, как страна и столица, книга и страницы. Для примера совокупного отношения, возьмите команду и игроков, игрок может существовать без команды, и команда-это группа игроков, и жизнь игрока может начаться до жизни команды, если мы говорим о программировании, мы можем создавать игроков и после того, как мы создадим команду, но для композиции нет, мы создаем комнату внутри дома . Композиция - - - - > композит / композиция. Агрегация - - - - - - - > группа | Элемент

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

далее от стандарта UML:

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

Итак, Ассоциация университет-соборы-это композиция, потому что cathedra не существует вне университета (IMHO)

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

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

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

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

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