Чем отличается агрегация от композиции?

угадал автора по тегам

В агрегации времена жизни агрегирующего и агрегируемых объектов никак не связаны

а можно пример какой нибудь, пожалуйста? А то как то не очень понятно:)

И что это дает, вообще, в контексте проектирования. Где нужна развязка между временами жизни, для каких задач?

https://softwareengineering.stackexchange.com/questions/61376/aggregation-vs-...

спасибо. Прочитал ссылку.

То есть, все сводится к тому что, грубо говоря, на псевдокоде

object.bind(newInstanceOfSomeClass)

-- это будет композиция, потому что с исчезновением object, исчезнет и инстанс, а

object.bind(existentInstanceOfSomeClass)

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

Правильно я понял?

Дата регистрации: 19.03.2017 13:16:56

http://www.adobe.com/devnet/actionscript/learning/oop-concepts/composition-an...

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

Что-то даже не уверен, что это касается сабжа. Зачем они там громоздят Person непосредственно в класс? В этом случае надо обеспечить возможность пребывания Person, а не делать его слотом. Или я код не понял.

Но интересно другое.

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

Например есть два мента и один стукач. Этот стукач является «информатором» и мента Васи, и мента Пети. Это будет агрегацией, правильно я понимаю?

Принадлежность Person к стулу может быть только временной, в какой-то момент кто-то сидит, в какой то сидит другой, в какой то никто не сидит.

Вот именно в этом и суть аггрегации. Так же как и человек не рождается с приросшим к нему стулом или допустим одеждой.

То есть агрегируемый объект должен быть непременно временным и меняться на другой?

Вообще, это противоречит той ссылке которую давали ранее. Вот цитата оттуда:

A «owns» B = Composition : B has no meaning or purpose in the system without A A «uses» B = Aggregation : B exists independently (conceptually) from A Example 1:

A Company is an aggregation of People. A Company is a composition of Accounts. When a Company ceases to do business its Accounts cease to exist but its People continue to exist.

Example 2: (very simplified)

A Text Editor owns a Buffer (composition). A Text Editor uses a File (aggregation). When the Text Editor is closed, the Buffer is destroyed but the File itself is not destroyed.

Мне почему то это кажется более правдоподобным:)

То есть агрегируемый объект должен быть непременно временным и меняться на другой?

Нет. Аггрегация ничего не говорит о времени жизни объектов. Человек не умирает вставая со стула, а стул не расстворяетс в пространстве, когда человек с его овстает. Оба могут дальше прекрасно существовать по-отдельности.

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

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

Ну, для случая с композицией этот пример не корректен. Там наоборот, голова умирает с человеком:)

То есть, если мы удаляем человека, голову сгребет GC, ссылек на нее больше ниоткуда нет, то уникальный объект, я так понимаю

То есть, если мы удаляем человека, голову сгребет GC

При чем тут GC?

Композиция и аггрегация - совершенно абстрактные и не связанные с языками программирования модели описывающие связь объектов друг с другом. Всё.

ну а что значит в таком случае ваш пример? Если экстраполировать это на пример по Вашей ссылке, пример композиции со стулом: по Вашей логике, стул исчезает когда исчезает его ножке, но это не так:) Стул просто будет трехногим, стул-инвалид, он никуда не исчезнет:)

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

Если это будет предусмотренно - ножки у стула должны быть аггрегацией. Это будет совсем другая модель (стула из Ikea :D), позволяющая разбирать стул на части.

То есть, согласно последней твоей версии композиция от агрегации отличается тем, что там запрещены изменения?

то есть, любой иммутабельный объект является частным случаем композиции?

То есть, согласно последней твоей версии

Что значит последней да еще и версии?

композиция от агрегации отличается тем, что там запрещены изменения?

Нет. Можно менять параметры объекта и объектов композиции (магина и двигатель - обороты).

то есть, любой иммутабельный объект является частным случаем композиции?

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

man схоластика

затем

многосортные алгебры

опп это какоё-то модное гсм ибо вместо описание ооп через мат описывают через анимализм идей - та да уж Аристотелеву(али ещё кого) иерархию идей.

*анимизм

зы. сорян.

Нет. Можно менять параметры объекта и объектов композиции (магина и двигатель - обороты).

Ок. То есть можно обобщить это до такого:

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

Правильно я понял?

Я конечно не знаю, может ты и прав, но вообще, например в определении википедии нет такого требования:

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

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

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

class CompositeCustomService
{
    // Композиция
    private readonly CustomRepository _repository
          = new CustomRepository();
    public void DoSomething()
    { 
        // Используем _repository
    }
}

class AggregatedCustomService
{ 
    // Агрегация
    private readonly AbstractRepository _repository; 
    public AggregatedCustomService(AbstractRepository repository) 
    { 
        _repository = repository; 
    } 
    public void DoSomething() 
    { 
        // Используем _repository
    }
}

Ну, я так и думал, спасибо.

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