В чем разница между ассоциацией, агрегацией и составом?

В чем разница между ассоциацией, агрегацией и составом? Пожалуйста, объясните с точки зрения реализации.

316
20 мая '09 в 5:47
источник поделиться
20 ответов
  • Ассоциация - это связь, в которой все объекты имеют собственный жизненный цикл, и нет владельца.

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

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

    Возьмем пример Департамента и учителя. Один преподаватель не может принадлежать нескольким отделам, но если мы удалим отдел, объект учителя не будет уничтожен. Мы можем думать об этом как о "has-a".

  • Состав - это снова специализированная форма агрегации, и мы можем назвать это как "смерть". Это сильный тип агрегирования. У дочернего объекта нет жизненного цикла, и если родительский объект удален, все дочерние объекты также будут удалены.

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

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

475
27 дек. '12 в 8:55
источник

Для двух объектов, Foo и Bar могут быть определены отношения

Ассоциация - у меня есть отношения с объектом. Foo использует Bar

public class Foo { 
    void Baz(Bar bar) {
    } 
};

Композиция - я владею объектом и отвечаю за его жизнь. Когда умирает Foo, Bar тоже

public class Foo {
    private Bar bar = new Bar(); 
}

Агрегация - у меня есть объект, который я позаимствовал у кого-то другого. Когда Foo умирает, Bar может жить дальше.

public class Foo { 
    private Bar bar; 
    Foo(Bar bar) { 
       this.bar = bar; 
    }
}
281
01 мая '12 в 10:20
источник

Я знаю, что этот вопрос помечен как С#, но концепции являются довольно общими вопросами, такими как перенаправление здесь. Так что я собираюсь изложить свою точку зрения здесь (немного предвзято с точки зрения Java, где мне удобнее).

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

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

enter image description here

  • И в агрегации, и в композиции объект одного класса "владеет" объектом другого класса.
  • Но есть небольшая разница. В композиции объект класса, принадлежащий объекту класса-владельца, не может жить сам по себе (также называемый "смертью отношений"). Он всегда будет жить как часть своего объекта-владельца, где, как и в Агрегации, зависимый объект является автономным и может существовать, даже если объект класса-владельца мертв.
  • Таким образом, по составу, если владелец объекта является сборщиком мусора, будет принадлежать и принадлежащий объект, чего не происходит при агрегации.

Смущенный?

Пример композиции: рассмотрим пример автомобиля и двигателя, который очень специфичен для этого автомобиля (то есть его нельзя использовать ни в одном другом автомобиле). Этот тип отношений между классом Car и SpecificEngine называется Composition. Объект класса Car не может существовать без объекта класса SpecificEngine, а объект класса SpecificEngine не имеет значения без класса Car. Проще говоря, класс Car является единственным владельцем класса SpecificEngine.

Пример агрегации: теперь рассмотрим класс Car и класс Wheel. Автомобиль нуждается в объекте Колесо, чтобы функционировать. Значение объекта Car имеет собственный объект Wheel, но мы не можем сказать, что объект Wheel не имеет значения без объекта Car. Это может очень хорошо использоваться в Велосипеде, Грузовике или другом Объекте Автомобилей.

Подводя итог -

Подводя итог, можно сказать, что ассоциация - это очень общий термин, используемый для обозначения того, когда в классе используются функции, предоставляемые другим классом. Мы говорим, что это композиция, если один объект родительского класса владеет другим объектом дочернего класса, и этот объект дочернего класса не может существенным образом существовать без объекта родительского класса. Если это возможно, то это называется Агрегация.

Подробнее здесь. Я являюсь автором http://opensourceforgeeks.blogspot.in и добавил ссылку выше на соответствующий пост для большего контекста.

94
09 нояб. '14 в 15:38
источник

Ассоциация является обобщенной концепцией отношений. Включает в себя как состав, так и агрегацию.

Композиция (смесь) - это способ объединить простые объекты или типы данных в одну единицу. Композиции являются важным строительным блоком многих базовых структур данных.

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

Оба обозначают отношения между объектами и отличаются только их силой.

Trick помнить разницу: есть A - A ggregation и O шп - с O mpositoin

enter image description here

Теперь давайте посмотрим на следующее изображение

relations

enter image description here

Аналогия:

Композиция: Следующая картинка представляет собой композицию изображения, т.е. использует отдельные изображения, составляющие одно изображение.
enter image description here

Агрегация: коллекция изображений в одном месте

enter image description here

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

61
24 июля '15 в 3:01
источник

Зависимость (ссылки)
Это означает, что между двумя объектами нет концептуальной связи. например, объект объекта "Зачисление". Объекты Student & Course (как параметры метода или типы возврата)

public class EnrollmentService {
    public void enroll(Student s, Course c){}
}

Ассоциация (имеет-a)
Это означает, что почти всегда есть связь между объектами (они связаны). Объект Order имеет объект Customer

public class Order {
    private Customer customer
}

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

public class PlayList{
    private List<Song> songs;
}

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

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

public class Apartment{
    private Room bedroom;
    public Apartment() {
       bedroom = new Room();
    }
}
33
03 дек. '15 в 18:24
источник

Из сообщения Роберт Мартин в comp.object:

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

//[Example:]

//|A|----------->|B|

class A
{
  private:
    B* itsB;
};

Агрегация [...] - это типичное отношение целого/части. Это точно так же, как и ассоциация с исключением того, что экземпляры не могут иметь циклические отношения агрегации (т.е. Часть не может содержать ее целое).

//[Example:]

//|Node|<>-------->|Node|

class Node
{
  private:
    vector<Node*> itsNodes;
};

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

Композиция [...] точно такая же, как Агрегация, за исключением того, что время жизни "части" контролируется "целым". Этот контроль может быть прямым или транзитивным. То есть "целое" может взять на себя прямую ответственность за создание или уничтожение "части", или оно может принять уже созданную часть, а затем передать ее другому целому, которое берет на себя ответственность за это.

//[Example:]

//|Car|<#>-------->|Carburetor|

class Car
{
  public:
    virtual ~Car() {delete itsCarb;}
  private:
    Carburetor* itsCarb
};
28
01 февр. '10 в 10:15
источник

Как говорили другие, ассоциация - это взаимосвязь между объектами, агрегация и композиция - это типы ассоциации.

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

class A {
    B & element;
  // or B * element;
};

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

class A {
    B element;
};

Здесь, когда объект A уничтожается, объект B, который он содержит, также будет уничтожен. Самый простой способ добиться этого - сохранить элемент по значению, но вы также можете использовать некоторый умный указатель или удалить член в деструкторе:

class A {
    std::auto_ptr<B> element;
};

class A {
    B * element;

    ~A() {
        delete B;
    }
};

Важным моментом является то, что в композиции объект-контейнер владеет содержащим его, тогда как в агрегации он ссылается.

20
20 мая '09 в 11:16
источник

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

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

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

Насколько я вижу, эта путаница имеет два корня:

  1. В сообществе C++ термин "агрегация" использовался в смысле класса, определяющего атрибут для ссылки на объекты другого независимого класса (см., Например, [1]), что является смыслом ассоциации в диаграммах классов UML, Термин "композиция" использовался для классов, которые определяют объекты объектов для своих объектов, так что при уничтожении составного объекта эти объекты компонентов также уничтожаются.

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

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

См. Также мой расширенный ответ на вопрос SO в апреле 2009 года, приведенный ниже.

И свойство, которое предполагалось определить "состав" между объектами ООП в сообществе C++ (и это мнение по-прежнему широко распространено): зависимость жизненного цикла между двумя связанными объектами (составной и его компонент), на самом деле не характерно для "композиции", потому что мы можем иметь такие зависимости из-за ссылочной целостности и в других типах ассоциаций.

Например, в ответе SO была предложена следующая схема кода для "композиции":

final class Car {    
  private final Engine engine;

  Car(EngineSpecs specs) {
    engine = new Engine(specs);
  }

  void move() {
    engine.work();
  }
}

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

[1] http://www.learncpp.com/cpp-tutorial/103-aggregation/

Приложение - Неполный список неоднократно задаваемых вопросов о составе по сравнению с агрегацией на StackOverflow

[ Апрель 2009 ]
Агрегация и композиция [закрыты, в основном, основанные на мнениях]
[ Апрель 2009 ]
В чем разница между композицией и ассоциацией? [ Май 2009 ]
Разница между ассоциацией, агрегацией и составом
[ Май 2009 ]
В чем разница между составом и агрегацией? [Дубликат]
[ Октябрь 2009 ]
В чем разница между агрегацией, составом и зависимостью? [отмечены как дубликаты]
[ Ноя 2010 ]
Ассоциация против агрегирования [отмечена как дубликат]
[ Август 2012 ]
Разница между агрегацией и композицией в Java
[ Февраль 2015 ]
UML - объединение или агрегация (простые фрагменты кода)

12
05 февр. '16 в 4:08
источник

Ассоциация

Ассоциация представляет взаимосвязь между двумя классами. Она может быть однонаправленной (в одну сторону) или двунаправленной (двухсторонней).

например:

  • однонаправленный

Клиент размещает заказы

  1. двунаправленным

A женат на B

B женат на A

Агрегация

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

например:

У клуба есть члены

Клуб ( "весь" ) состоит из нескольких членов клуба ( "части" ). У члена есть жизнь вне клуба. Если клуб ( "целое" ) должен был умереть, члены ( "части" ) не умерли бы вместе с ним. Поскольку член может принадлежать нескольким клубам ( "целые" ).

Состав

Это более сильная форма агрегации. "Целый" несет ответственность за создание или уничтожение своих "частей"

Например:

В школе есть отделы

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

11
13 июля '16 в 20:51
источник

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

ассоциация

Самый абстрактный способ описать статические отношения между классами - это использовать ссылку "Ассоциация", которая просто утверждает, что существует какая-то связь или зависимость между двумя классами или более.

Слабая Ассоциация

ClassA может быть связан с ClassB для того, чтобы показать, что один из его методов включает параметр экземпляра ClassB или возвращает экземпляр ClassB.

Сильная Ассоциация

ClassA также может быть связан с ClassB, чтобы показать, что он содержит ссылку на экземпляр ClassB.

Агрегация (Общая Ассоциация)

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

enter image description here

Важно отметить, что ссылка агрегации ни в коем случае не указывает, что ClassA владеет ClassB, и что между ними есть родительско-дочерние отношения (когда родитель удалил все его дочерние элементы, удаляемые в результате). На самом деле, совсем наоборот! Ссылка агрегации обычно используется для подчеркивания того факта, что ClassA не является эксклюзивным контейнером ClassB, поскольку на самом деле ClassB имеет другой контейнер.

Агрегация против ассоциации Ссылка ассоциации может заменить ссылку агрегации в любой ситуации, в то время как агрегация не может заменить ассоциацию в ситуациях, когда существует только слабая связь между классами, то есть ClassA имеет метод (ы), которые содержат параметр ClassB, но ClassA не содержит ссылку на ClassB экземпляр.

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

Композиция (Не разделяемая ассоциация)

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

enter image description here

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

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

Измерительная система сложности

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

Вы можете прочитать больше в моем блоге: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html


11
20 февр. '17 в 8:31
источник

Связь между двумя объектами называется ассоциацией.

Ассоциация известна как состав, когда один объект владеет другим.

Хотя ассоциация известна как агрегация, когда один объект использует другой объект.

6
24 авг. '16 в 22:11
источник

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

Я собираюсь основываться на некоторых кратких чтениях многих сообщений о SO и некоторых документах UML, что есть 4 основные конкретные формы ассоциации классов:

  • состав: A составлен из B; B не существует без A, как комната в доме
  • агрегация: A имеет-a B; B может существовать без A, как ученик в классе.
  • зависимость: A использует-a B; нет зависимости жизненного цикла между A и B, как параметр вызова метода, возвращаемое значение или временное, созданное во время вызова метода
  • обобщение: A is-a B

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

Я предполагаю, что "общая ассоциация" предназначена для использования в основном в двух обстоятельствах:

  • когда детали отношений все еще разрабатываются; такая связь на диаграмме должна быть как можно скорее преобразована в то, что она на самом деле есть/будет (одна из остальных 4).
  • когда отношение не соответствует ни одному из этих 4, заранее определенных UML; "общая" ассоциация по-прежнему дает вам способ представления отношения, которое "не является одним из других", так что вы не застреваете, используя неправильную связь с запиской "это не на самом деле агрегация, это просто то, что UML не имеет другого символа, который мы могли бы использовать"
5
19 дек. '16 в 23:04
источник

Композиция (при удалении "целого" "часть" также удаляется автоматически - "Владение")

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

  • Обычно используют обычные переменные-члены.

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

enter image description here

Композиция в C++

#include <iostream>
using namespace std;
/********************** Engine Class ******************/
class Engine
{
    int nEngineNumber;
    public:
    Engine(int nEngineNo);
    ~Engine(void);
};
Engine::Engine(int nEngineNo)
{
    cout<<" Engine :: Constructor " <<endl;
}
Engine::~Engine(void)
{
    cout<<" Engine :: Destructor " <<endl;
}
/********************** Car Class ******************/
class Car
{
    int nCarColorNumber;
    int nCarModelNumber;
    Engine objEngine;
    public:
    Car (int, int,int);
    ~Car(void);
};
Car::Car(int nModelNo,int nColorNo, int nEngineNo):
nCarModelNumber(nModelNo),nCarColorNumber(nColorNo),objEngine(nEngineNo)
{
    cout<<" Car :: Constructor " <<endl;
}
Car::~Car(void)
{
    cout<<" Car :: Destructor " <<endl;
    Car
    Engine
    Figure 1 : Composition
}
/********************** Bus Class ******************/
class Bus
{
    int nBusColorNumber;
    int nBusModelNumber;
    Engine* ptrEngine;
    public:
    Bus(int,int,int);
    ~Bus(void);
};
Bus::Bus(int nModelNo,int nColorNo, int nEngineNo):
nBusModelNumber(nModelNo),nBusColorNumber(nColorNo)
{
    ptrEngine = new Engine(nEngineNo);
    cout<<" Bus :: Constructor " <<endl;
}
Bus::~Bus(void)
{
    cout<<" Bus :: Destructor " <<endl;
    delete ptrEngine;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    // Composition using simple Engine in a car object
    {
        cout<<"------------- Inside Car Block ------------------"<<endl;
        Car objCar (1, 2,3);
    }
    cout<<"------------- Out of Car Block ------------------"<<endl;
    // Composition using pointer of Engine in a Bus object
    {
        cout<<"------------- Inside Bus Block ------------------"<<endl;
        Bus objBus(11, 22,33);
    }
    cout<<"------------- Out of Bus Block ------------------"<<endl;
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

Выход

--------------- Start Of Program --------------------
------------- Inside Car Block ------------------
Engine :: Constructor
Car :: Constructor
Car :: Destructor
Engine :: Destructor
------------- Out of Car Block ------------------
------------- Inside Bus Block ------------------
Engine :: Constructor
Bus :: Constructor
Bus :: Destructor
Engine :: Destructor
------------- Out of Bus Block ------------------
--------------- End Of Program --------------------

Агрегирование (если удалить "весь", "Часть" может существовать - "Нет собственности")

  • Агрегация - это особый тип композиции, где не подразумевается право собственности между сложным объектом и подобъектами. Когда агрегат уничтожается, подобъекты не уничтожаются.

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

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

  • Не несет ответственности за создание/уничтожение подклассов

enter image description here

Код агрегации в C++

#include <iostream>
#include <string>
using namespace std;
/********************** Teacher Class ******************/
class Teacher
{
    private:
    string m_strName;
    public:
    Teacher(string strName);
    ~Teacher(void);
    string GetName();
};
Teacher::Teacher(string strName) : m_strName(strName)
{
    cout<<" Teacher :: Constructor --- Teacher Name :: "<<m_strName<<endl;
}
Teacher::~Teacher(void)
{
    cout<<" Teacher :: Destructor --- Teacher Name :: "<<m_strName<<endl;
}
string Teacher::GetName()
{
    return m_strName;
}
/********************** Department Class ******************/
class Department
{
    private:
    Teacher *m_pcTeacher;
    Teacher& m_refTeacher;
    public:
    Department(Teacher *pcTeacher, Teacher& objTeacher);
    ~Department(void);
};
Department::Department(Teacher *pcTeacher, Teacher& objTeacher)
: m_pcTeacher(pcTeacher), m_refTeacher(objTeacher)
{
    cout<<" Department :: Constructor " <<endl;
}
Department::~Department(void)
{
    cout<<" Department :: Destructor " <<endl;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    {
        // Create a teacher outside the scope of the Department
        Teacher objTeacher("Reference Teacher");
        Teacher *pTeacher = new Teacher("Pointer Teacher"); // create a teacher
        {
            cout<<"------------- Inside Block ------------------"<<endl;
            // Create a department and use the constructor parameter to pass the teacher to it.
            Department cDept(pTeacher,objTeacher);
            Department
            Teacher
            Figure 2: Aggregation
        } // cDept goes out of scope here and is destroyed
        cout<<"------------- Out of Block ------------------"<<endl;
        // pTeacher still exists here because cDept did not destroy it
        delete pTeacher;
    }
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

Выход

--------------- Start Of Program --------------------
Teacher :: Constructor --- Teacher Name :: Reference Teacher
Teacher :: Constructor --- Teacher Name :: Pointer Teacher
------------- Inside Block ------------------
Department :: Constructor
Department :: Destructor
------------- Out of Block ------------------
Teacher :: Destructor --- Teacher Name :: Pointer Teacher
Teacher :: Destructor --- Teacher Name :: Reference Teacher
--------------- End Of Program --------------------
5
13 марта '18 в 13:14
источник

Ассоциация Мы называем ассоциацией те отношения, объекты которых имеют независимый жизненный цикл и где нет собственности между объектами.

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

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

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

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

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

4
06 дек. '17 в 21:39

Состав: Это когда вы уничтожаете объект (Школа), другой объект (классные комнаты), который связан с ним, тоже будет уничтожен. Оба они не могут существовать независимо.

Агрегация: Это как раз противоположная вышеприведенная (Composition) ассоциация, где, когда вы убиваете объект (Company), другой объект (Employees), который связан с ним, может существовать сам по себе.

Ассоциация.
Состав и агрегация являются двумя формами ассоциации.

4
15 окт. '17 в 15:40
источник

Я думаю, что эта ссылка сделает вашу домашнюю работу: http://ootips.org/uml-hasa.html

Чтобы понять термины, которые я помню, например, в ранние дни программирования:

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

Если у вас есть "квадратный" объект, у которого есть "цветной" объект, и квадрат удаляется, объект "цвет" может все еще существовать, то есть агрегация

Оба из них являются ассоциациями, основное отличие концептуально

4
20 мая '09 в 6:07
источник

Я хотел бы проиллюстрировать, как три условия реализованы в Rails. ActiveRecord вызывает любые отношения между двумя моделями association. При чтении документации или статей, связанных с ActiveRecord, не часто встречались термины composition и aggregation. Связь создается добавлением одного из макросов класса ассоциации в тело класса. Некоторые из этих макросов: belongs_to, has_one, has_many и т.д.

Если мы хотим установить composition или aggregation, нам нужно добавить belongs_to в принадлежащую ему модель (также называемую дочерним) и has_one или has_many к модели-владельцу (также называемой родительской). Wether, который мы установили composition или aggregation, зависит от параметров, которые мы передаем в вызов belongs_to в дочерней модели. До Rails 5, настроив belongs_to без каких-либо параметров, созданных aggregation, ребенок мог существовать без родителя. Если бы мы хотели composition, нам нужно было явно объявить это, добавив опцию required: true:

class Room < ActiveRecord::Base
  belongs_to :house, required: true
end

В Rails 5 это было изменено. Теперь, объявив, что ассоциация belongs_to создает composition по умолчанию, ребенок не может существовать без родителя. Таким образом, приведенный выше пример можно переписать следующим образом:

class Room < ApplicationRecord
  belongs_to :house
end

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

class Product < ApplicationRecord
  belongs_to :category, optional: true
end
2
12 сент. '17 в 14:17
источник

Ясное понимание Ассоциации, Агрегация, Состав и другие отношения классов UML можно найти здесь Понимание отношений класса UML

0
06 дек. '17 в 21:38

Ассоциация, агрегация и состав

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

1. Ассоциация на Яве

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

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

enter image description here

2. Агрегация в Java

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

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

enter image description here

3. Композиция на Java

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

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

enter image description here

4. Резюме

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

enter image description here

0
15 янв. '19 в 17:09
источник

В очень простом предложении:
Агрегация и состав являются подмножествами ассоциации.

  • A использует B → это агрегация

  • А нужен Б → это композиция.

Узнайте больше здесь.

-1
04 окт. '18 в 23:27
источник

Посмотрите другие вопросы по меткам или Задайте вопрос