Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?

Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?

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

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

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

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


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

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

Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?

[Трёпа ради прилечу.]
Если композиция такова, что объект-целое обязателен, и объект-часть обязателен, и объект-часть не может существовать сам по себе, например, Здание◆-1---1..*-Этаж, то обязательный этаж здания должен создаваться в конструкторе здания. Любой строитель подтвердит. (Экзотику, когда берут этаж от одного здания и передают в другое, не рассматриваем.)
Если композиция такова, что объект-целое необязателен, , а объект-часть обязателен, и объект часть может существовать сам по себе, например, Авто◆-0..1---3..8-Колесо, то три обязательных колёса можно создавать раньше авто и передавать ему при вызове конструктора.
Т. е. исходный вопрос не про композицию/агрегацию, а про композицию со специфическими мощностями.

[Трёпа ради прилечу.]
Если композиция такова, что объект-целое необязателен, , а объект-часть обязателен, и объект часть может существовать сам по себе, например, Авто◆-0..1---3..8-Колесо, то три обязательных колёса можно создавать раньше авто и передавать ему при вызове конструктора.

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

Про колесо придумал Конрад Бок: http://www.jot.fm/issues/issue_2004_11/column5/
Это один из "друзей" "3-х друзей" -- в смысле, разработчик стандарта.

Про колесо придумал Конрад Бок: http://www.jot.fm/issues/issue_2004_11/column5/
Это один из "друзей" "3-х друзей" -- в смысле, разработчик стандарта.

И что. Мне следует пасть ниц? Если нелогично, почему нужно следовать авторитету?

Я лишь попыталось пояснить свой ответ.

Я лишь попыталось пояснить свой ответ.

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

Давайте по понятиям?? Пройдемся ...

Семантика umlьная. Другой на моей планете нет, не завезли.

[deleted]

Я с планеты 7ми пятниц.
Как бы не соскочить в офтопик и не раздосадовать модератора.

Пока модераторы спят .. на страницы форума пробираются инопланетяне

"Don’t worry about the diamonds" -- наставляет Скот Амблер в своём "The Elements of UML 2.0 Style". При этом на его диаграмму из сопроводиловки лучше не смотреть, чтобы не терзаться популярным на здешней планете вопросом: "А что у Вас, ребята, в головах?"

Композиция: Элемент-источник является частью и не может существовать без целевого элемента.
Агрегация: Элемент-источник является частью и может существовать отдельно целевого элемента.

Композиция: Элемент-источник является частью и не может существовать без целевого элемента.

А если при черном ромбе будет не 1..1, а 0..1?

Агрегация: Элемент-источник является частью и может существовать отдельно целевого элемента.

А если при белом ромбе будет 1..1 или 1..*?

Конечно при условии:

Семантика umlьная. Другой на моей планете нет, не завезли.