Дисциплины > Реализация
Композиция, Агрегация
Максим:
Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?
Григорий Печенкин:
--- Цитата: Максим от 23 Октября 2014, 16:56:00 ---Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?
--- Конец цитаты ---
Нет однозначного соответствия между отношениями и способом реализации в коде. И композицию, и агрегацию можно реализовать одним и тем же кодом.
Можно устанавливать связь в конструкторе и разрывать в деструкторе. Имеет смысл, если агрегируемый используется объект на всём протяжении жизни агрегатора.
Можно использовать отдельную функцию инициализации объекта, вызываемую после его создания.
Можно подключать и отключать агрегируемые объекты отдельными методами, например, при обработке событий. Имеет смысл, если в процессе жизни агрегатора агрегируемые объекты могут изменяться. Или если агрегатор может выполнять какие-то функции вообще без агрегируемых объектов.
Вообще, по моему мнению, однозначное соответствие между моделью отношений и кодом возможно только в самых примитивных проектах - по большей части учебных. В реальной жизни всегда находится компромисс между соответствием абстрактной модели, читаемостью, сопровождаемостью и универсальностью кода, совместимостью с существующими наработками и прочими нефункциональными требованиями, вроде требований к производительности.
Максим:
Получается, что связь между классом контейнером и включаемыми в него объектами можно установить как в теле конструктора, так и в любом другом методе этого класса, в любое время. Если объекты создаются в теле конструктора или любого другого метода, то это композиция. Если же объекты приходят извне и передаются как аргументы конструктора или метода, то это агрегация. Таким образом мы уже будем знать что произойдет с включаемыми объектами после уничтожения класса-контейнера. В случае ассоциации же, в классе просто объявляются объектные поля без уточнения как будет устанавливаться связь, т.е. откуда будут приходить включаемые объекты снаружи класса или создаваться в этом контейнере. Верно я понял реализацию этих трех отношений?
[прилетело НЛО и...]:
--- Цитата: Максим от 23 Октября 2014, 16:56:00 ---Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?
--- Конец цитаты ---
[Трёпа ради прилечу.]
Если композиция такова, что объект-целое обязателен, и объект-часть обязателен, и объект-часть не может существовать сам по себе, например, Здание◆-1---1..*-Этаж, то обязательный этаж здания должен создаваться в конструкторе здания. Любой строитель подтвердит. (Экзотику, когда берут этаж от одного здания и передают в другое, не рассматриваем.)
Если композиция такова, что объект-целое необязателен, , а объект-часть обязателен, и объект часть может существовать сам по себе, например, Авто◆-0..1---3..8-Колесо, то три обязательных колёса можно создавать раньше авто и передавать ему при вызове конструктора.
Т. е. исходный вопрос не про композицию/агрегацию, а про композицию со специфическими мощностями.
Galogen:
--- Цитата: [прилетело НЛО и...] от 14 Сентября 2017, 22:00:11 ---[Трёпа ради прилечу.]
Если композиция такова, что объект-целое необязателен, , а объект-часть обязателен, и объект часть может существовать сам по себе, например, Авто◆-0..1---3..8-Колесо, то три обязательных колёса можно создавать раньше авто и передавать ему при вызове конструктора.
--- Конец цитаты ---
Простите, но это же агрегация, а не композиция. Колесо же не может быть произведено как часть необязательной композиции. Это нонсенс, но может быть произведено само себе и употреблено как часть автомобиля. Другое дело, что автомобиль накладывает определенные ограничения на вид такого колеса
Навигация
Перейти к полной версии