Агрегация по сравнению с композицией

Ответ 1

Различие между агрегацией и композицией зависит от контекста.

Возьмите пример автомобиля, упомянутый в другом ответе - да, это правда, что выхлопная труба автомобиля может стоять "сама по себе", поэтому не может быть в составе с автомобилем, но это зависит от приложения. Если вы создаете приложение, которое действительно должно иметь дело с автономными выхлопами автомобилей (приложение для управления автомобильным магазином?), Вам будет выбран агрегат. Но если это простая гоночная игра, а выхлопная труба только служит частью автомобиля - ну, композиция будет неплохой.

Шахматная доска? Та же проблема. Шахматная фигура не существует без шахматной доски только в определенных приложениях. В других (например, производитель игрушек) шахматная фигура, несомненно, не может быть составлена ​​на шахматной доске.

Все становится еще хуже, когда вы пытаетесь сопоставить композицию/агрегацию с вашим любимым языком программирования. На некоторых языках разница может быть легче заметить ( "по ссылке" и "по значению", когда все просто), но в других может вообще не существовать.

И последнее слово совета? Не тратьте слишком много времени на эту проблему. Это не стоит. Различие вряд ли полезно на практике (даже если у вас есть совершенно понятный "состав", вы все равно можете реализовать его как агрегацию по техническим причинам - например, кеширование).

Ответ 2

Как правило:

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

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

В композиции (Person, Heart, Hand), "sub objects" ( "Сердце, рука" ) будут уничтожены, как только персонаж будет уничтожен.

В агрегации (Город, Дерево, Автомобиль) "под-объекты" (Дерево, Автомобиль) НЕ будут уничтожены, когда Город разрушен.

Суть в том, что составные стрессы на взаимном существовании, и в агрегации это свойство НЕ требуется.

Ответ 3

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

Ответ 4

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

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

// 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");
  }
}

Разъяснение здесь с примером Разница между агрегацией и составом

Ответ 5

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

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

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

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

Ответ 6

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

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

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

Но в то же время они также говорят

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

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

1) Состав

Как объяснил Мартин Фаулер, основной проблемой для характеристики композиции является то, что "объект может быть только частью одного отношения композиции", Это также объясняется в отличном сообщении блога UML Composition vs Aggregation vs Association от Geert Bellekens. В дополнение к этой определяющей характеристике композиции (для эксклюзивных или не разделяемых частей) композиция может также иметь зависимость жизненного цикла между композитным и его компонентов. На самом деле существует два вида таких зависимостей:

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

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

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

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

2) Агрегация

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

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

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

Ответ 7

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

поэтому этот код...

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

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

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

Ответ 8

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

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

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

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

Кроме стандарта UML:

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

Таким образом, ассоциация Университета и кафедрального собора - это композиция, потому что кафедра не существует из университета (ИМХО)

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

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

Ответ 12

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

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

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