Да, существует много путаницы в отношении этих двух терминов Состав и Агрегация [Есть еще что добавить Shared и non-shared Агрегация].Пройдя через много путаницы и предвзятости по отношению к ресурсам UML, я сформировал свою точку зрения следующим образом [не нужно воспринимать ее как окончательную или точную].
Самое простое и слабосвязанное отношение, которое я беру, это Ассоциация [это может быть однонаправленная или двунаправленная ], где объект имеет ссылку на другой объект, но оба живут независимо.Ассоциация может быть Квалифицированная ассоциация , если она связана определенной идентификационной информацией [В ОО идентификационная информация является важной частью каждого объекта сущности], например, accountNumber для учетной записи клиента.
Агрегирование является коллекцией (других типов объектов и может быть собрана для ограниченных целей), поддерживаемой объектом.Все же оба объекта живут независимо.например, команда по легкой атлетике.Один и тот же ученик может быть частью многих таких команд, как команда велосипедистов [агрегаты] и так далее.Удаление команды легкой атлетики не наносит вреда каждой записи студента в записях колледжа [они все еще существуют].Такие отношения могут поддерживаться как сбор студентов на стороне команды или рекомендация команды по легкой атлетике для каждого студента, являющегося частью команды.Это зависит от более часто требуемой навигации для приложения.
Композиция - это более тесные отношения, когда контейнерный объект полностью содержит содержащийся объект, а содержащийся объект не имеет никакого значения вне отношений с контейнерным объектом.Я могу видеть пример отношения между человеком и адресом, где для каждого человека мы храним отдельную / свежую запись адреса.Для членов семьи адрес может иметь такое же логическое равенство, но не физическое равенство.Изменение адреса для одного члена не влияет на других участников [простой тест - столбцы БД для записи Персона имеют расширенные столбцы для адреса как часть таблицы персон.] Другой пример - Одиночная запись (строка) покупки товара и Полный перечень товаров.,где удаление bill делает каждую запись не зависящей от контекста.
Если объект создается и полностью содержит другой объект [никогда не позволяет внешнему миру получить свою ссылку любым способом], я бы принял это как Composition.Методы, такие как клонирование объектов в точках взаимодействия вместо передачи одной и той же ссылки, могут быть полезны здесь.В случае ассоциации или агрегации мы обмениваемся одинаковыми ссылками.
Сдерживание , являющееся черным ящиком повторное использование, предпочтительнее белого ящика вида повторного использования (реализовано с использованием наследования ).Большинство моделей GOF предлагают лучшие комбинации Containment для повторного использования и наследования для полиморфизма.Например, в случае шаблона Adapter, Object Adapter предпочтительнее, чем Class Adapter .
Реализация всех этих разновидностей в Java (реализации будут зависеть от языка) имеет свои собственные проблемыи НЕ очень прямолинейный, особенно композиция .На кривой обучения есть точка, где чувствуется (по крайней мере, я чувствовал) Композиция такая же, как внутренний класс , внутренний класс может помочь нам реализовать это, но просто наличие внутреннего класса делаетне дают никаких гарантий композиции.