Association, Aggregation and Composition #
В ООП(не только в Java) помимо наследования различают ещё три связи между объектами:
Мы говорим об агрегации, когда объект может быть частью нескольких составных объектов(компонентов). В этом случае полученный объект агрегирован. Срок службы деталей может быть больше, чем срок службы агрегата.
Association, Aggregation, Composition
В композиции деталь может содержаться только в одном композитном объекте, а срок службы композитного объекта всегда соответствует сроку службы его компонентов. Здесь составной объект называется композитным.
Примером композиции является связь между заказом на покупку и отдельными позициями заказа на покупку. Если заказ на покупку удаляется, то автоматически удаляются и все его элементы. Дом и квартира в нём. Если дом разрушить, то и квартира не может пережить разрушение дома.
Отношение между классами, которые не влияют друг на друга и не являются “родственниками” называют ассоциация. Иногда слово ассоциация используют как синоним слову отношения. На мой взгляд это немного запутывает. Но Java не единственный язык OOP и реализаций отношений между объектами возможно много больше, чем определений. Потому я не претендую на последнюю инстанцию. Но в своей статье использую “Association” для “простых связей” между объектами.
Пример ассоциации. Человек(Водитель) и легковая машина. Водитель может управлять машиной. Но каждый из них живёт своей собственной жизнью и не является частью другого.
Ни в какие рамки #
Студент и университет. Какая здесь связь?
По идее не композиция. Студенты точно не являются частью университета. Это и не наследование. Простая ассоциация или агрегация? Может это такой же случай как и футбольная команда. Может универ существовать без студентов или нет? Мы понимаем, что универ наверное немного сложнее, чем футбол, и в нём есть кафедры, специальности, потоки, курсы, группы. И вот группа скорее всего агрегация. Сама группа часть кафедры, а кафедры уже часть универа.
Порой надо понимать реализацию или упрощать связь до возможного описания в коде. Но в жизни всё может быть немного сложнее, чем в книге.
Я сделал маленькую табличку, которая должна помочь разобраться:
Таблица Association, Aggregation and Composition #
| — | Ассоциация | Агрегация | Композиция |
|---|---|---|---|
| Владелец | нет владельца | есть владелец | есть владелец |
| Жизненный цикл | собственный цикл жизни | собственный цикл жизни | Цикл жизни владельца |
“Пара” примеров отношений между классами #
Менеджер и карта, первый пример #
Это ассоциация. Объекты живут собственной жизнью. Объекты взаимодействуют друг с другом в одном из методов.
Java-программист работает на крупную IT-фирму #
Это ассоциация.
Java-программист в подчинении у менеджера, как и весь его отдел. #
Агрегация. Менеджер агрегировал весь отдел.
Менеджер, Проект, Зарплата 4 и 5 #
Композиция. Есть явная связь между зарплатой и проектом. Работой и проектом.
Просто о композиции, агрегации и ассоциации в JavaScript
Данная небольшая заметка о типах отношений между объектами в ООП. Можно использовать как шпаргалку, если кто знал, но подзабыл или, если для кого эти термины будут в новинку используйте как первый шаг в изучение основ ООП.
Композиция, агрегация и ассоциация — все эти термины или точнее парадигмы ООП про отношения между объектами или классами между собой. Всего существует пять основных типов отношений:
— Ассоциация
— Агрегарция
— Композиция
и еще два типа, которые в этой статье рассматривать не будем:
— Наследования (иногда этот тип еще называют генерализацией)
— Реализация (это тип отношений базируется на интерфейсах. То есть создается интерфейсы, которые основной класс должен реализовать.)
Композиция, агрегация и ассоциация эти три понятия очень похожи друг на друга. Все они означают что внутри одного объекта будет существовать другой объект.
Самый простой способ понять эти термины это использовать аналогию из реального мира. Представим себе что у нас есть класс комната и есть два других класса мебель и стена. Мы можем сказать что у комнаты будет какая та мебель и какие то стены. То есть объект комната может использоваться объекты стены и мебель по мере необходимости. Но есть разница в отношения комната — стены и комната — мебель. Разница в том что стены никогда не выйдут из объекта комната. Стены не могут существовать вне комнаты. То есть стена всегда будет создаваться внутри объекта комната. Такая связь называется композиция. И эта связь будет жесткой. Зато мебель очень легко представить за пределами комнаты. Один экземпляр мебели может принадлежать с начало одной комнате потом другой. Такая связь называется ассоциацией или агрегацией. И такая связь будет более гибкой. О различие между ассоциацией или агрегацией чуть позже.
Рассмотрим эти связи подробнее.
Ассоциация
Ассоциация это такой тип при котором объекты будут ссылаться друг на друга. При этом они остаются полностью независимыми друг от друга.
Пример реализации ассоциации
Тут у нас есть атрибут stream, в котором должна быть ссылка на поток который куда то будет отправлять сообщение. Метод log проверяет что в классе задан stream и использует его для отправки сообщения. То есть ассоциация это когда у одного класса есть ссылка на другой класс. Это создает большую гибкость в отношениях между классами. Например у нас есть возможность смены потока во время выполнения программы.
Агрегация
Агрегация это тип отношений когда один объект является частью другого. Агрегация образует слабую связь между объектами. Все зависимые классы инициализируются вне основного объекта.
Пример реализации агрегации:
При агрегации у нас получается более прочная связь, чем при ассоциации. В данном случае связь образуется при создание экземпляра класса Logger, в конструктор которого мы передаем другой класс.
Композиция
Композиция это тип отношений при котором один объект может принадлежать только другому объекту и никому другому. При композиции образуется сильная связь между объектами. При таком типе отношений основной объект полностью обеспечивает жизненный цикл объектов от которых он зависит. Используем еще один пример из реальной жизни. Возьмем машину и двигатель. Машина и двигатель конечно могут существовать друг без друга, но суть не в этом. А в том что при конкретной реализации рабочей машины, один двигатель может принадлежать только одной машине, поэтому для такой связи логично использовать композицию.
Пример реализации композиции
В данном случае внутри конструктора создается экземпляр другого класса. При этом создается более крепкая связанность этих двух классов. То есть класс Logger обязательно знает что существует библиотека fs, у него есть класс fs и у него есть метод createWriteStream и т. д. Он полностью знает реализацию другого класса.
То есть в ассоциации и агрегации предполагалось что эти два класса создается независимо, а потом связываются ссылками, в композиции они создается вместе в момент вызова конструктора.
Наследование, композиция, агрегация
Нередко случается, что решив разобраться с какой-то новой темой, понятием, инструментом программирования, я читаю одну за другой статьи на различных сайтах в интернете. И, если тема сложная, то эти статьи могут не на шаг не приблизить меня к понимаю. И вдруг встречается статья, которая моментально дает озарение и все паззлы складываются воедино. Трудно определить, что отличает такую статью от других. Правильно подобранные слова, оптимальная логика изложения или же просто более релевантный пример. Я не претендую на то, что моя статься окажется новым словом в C# или же лучшей обучающей статьей. Но, возможно для кого-то она станет именно той, которая позволит разобраться, запомнить и начать правильно применять те понятия, о которых пойдет речь.
В объектно-ориентированных языках программирования существует три способа организации взаимодействия между классами. Наследование — это когда класс-наследник имеет все поля и методы родительского класса, и, как правило, добавляет какой-то новый функционал или/и поля. Наследование описывается словом «является». Легковой автомобиль является автомобилем. Вполне естественно, если он будет его наследником.
Ассоциация – это когда один класс включает в себя другой класс в качестве одного из полей. Ассоциация описывается словом «имеет». Автомобиль имеет двигатель. Вполне естественно, что он не будет являться наследником двигателя (хотя такая архитектура тоже возможна в некоторых ситуациях).
Выделяют два частных случая ассоциации: композицию и агрегацию.
Композиция – это когда двигатель не существует отдельно от автомобиля. Он создается при создании автомобиля и полностью управляется автомобилем. В типичном примере, экземпляр двигателя будет создаваться в конструкторе автомобиля.
Агрегация – это когда экземпляр двигателя создается где-то в другом месте кода, и передается в конструктор автомобиля в качестве параметра.
Хотя ведутся дискуссии о преимуществах того или иного способа организации взаимодействия между классами, какого-либо абстрактного правила не существует. Разработчик выбирает тот или иной путь основываясь на элементарной логике (“является” или “имеет”), но также принимает во внимание возможности и ограничения, которые дают и накладывают эти способы. Для того, чтобы увидеть эти возможности и ограничения, я попытался написать пример. Достаточно простой, чтобы код оставался компактным, но и достаточно развитый, чтобы в рамках одной программы можно было применить все три способа. И, главное, я попытался сделать этот пример как можно менее абстрактным – все объекты и экземпляры понятны и осязаемы.
Напишем простенькую игру – танковый бой. Играют два танка. Они поочередно стреляют и проигрывает тот, здоровье которого упало до нуля. В игре будут различные типы снарядов и брони. Для того, чтобы нанести урон необходимо во-первых, попасть по танку противника, во-вторых, пробить его броню. Если броня не пробита, урон не наносится. Логика игры построена на принципе «камень-ножницы-бумага»: то есть броня одного типа хорошо противостоит снарядам определенного типа, но плохо держит другие снаряды. Кроме того, снаряды, которые хорошо пробивают броню, наносят малый «заброневой» урон, и, напротив, наиболее «летальные» снаряды имеют меньше шансов пробить броню.
Создадим простенький класс для пушки. Он будет иметь два приватных поля: калибр и длину ствола. От калибра зависит урон, и, частично, способность к пробитию брони. От длины ствола – точность стрельбы.
Сделаем также конструктор для пушки:
Сделаем метод для получения калибра из других классов:
Помните, что для поражения цели должно произойти две вещи: попадание в цель и пробитие брони? Так вот, пушка будет отвечать за первую из них: попадание. Поэтому делаем булевый метод IsOnTarget, который принимает случайную величину (dice) и возвращает результат: попали или нет:
Целиком класс пушки выглядит следующим образом:
Здесь мы применили агрегацию. Где-то будет создана пушка. Потом к этой пушке будут создаваться снаряды, которые имеют указатель на пушку.
Теперь сделаем разные типы снарядов, которые будут наследовать абстрактный снаряд: фугасный, кумулятивный, подкалиберный. Фугасный наносит самый большой урон, кумулятивный – меньше, подкалиберный – еще меньше. Дочерние классы не имеют полей и вызывают конструктор базового снаряда, передавая ему пушку, и строковый тип. В дочернем классе переопределяется метод GetDamage() – вносятся коэффициенты, которые увеличат или уменьшат урон по сравнению с дефолтным.
Фугасный (дефолтный урон):
Кумулятивный (дефолтный урон х 0.6):
Подкалиберный (дефолтный урон х 0.3):
Обратите внимание, что в переопределенном методе GetDamage вызывается и метод базового класса. То есть, переопределив метод, мы также сохраняем возможность обратиться к дефолтному методу, использовав ключевое слово base).
Итак, для снарядов мы применили и агрегацию (пушка в базовом классе), и наследование.
Создадим теперь броню для танка. Здесь применим только наследование. Любая броня имеет толщину. Поэтому абстрактный класс брони будет иметь поле thickness, и строковое поле type, которое будет определятся при создании дочерних классов.
Броня будет в нашей игре определять пробита они или нет. Поэтому, у нее будет лишь один метод, который будет переопределяться в дочерних, в зависимости от типа брони.
Для того, чтобы конструктор танка остался более-менее компактным, сделаем два вспомогательных приватных метода, которые добавляют три типа брони соответствующей толщины, и наполняют боеукладку 10 снарядами каждого из трех типов:
Теперь конструктор танка выглядит вот таким образом:
Пользовательский интерфейс танка состоит из трех методов: выбрать броню, зарядить пушку, выстрелить.
Как я упомянул в начале, в этом примере я старался максимально уйти от абстрактных понятий, которые нужно все время держать в голове. Поэтому каждый экземпляр снаряда у нас равен физическому снаряду, который положили в боеукладку перед боем. Следовательно, снаряды могут закончится в самый неподходящий момент!
Этот интерфейс требует реализации метода Clone(). Вот она:
Теперь все супер реалистично: при выстреле генерируется dice, пушка рассчитывает попадание своим методом IsOnTarget, и, если попадание есть, то метод Shoot вернет экземпляр снаряда, а если промах – то вернет null.
Последний метод танка – его поведение при попадании вражеского снаряда:
Все готово. Остается только написать консольный (или неконсольный) вывод, в котором будет обеспечен пользовательский интерфейс и в цикле реализованы поочередные ходы игроков.
Подведем итоги. Мы написали программу, в которой использовали наследование, композицию и агрегацию, надеюсь, поняли и запомнили различия. Активно задействовали возможности полиморфизма, во-первых, когда любые экземпляры дочерних классов можно сложить в список, имеющий тип данных родительского, а во-вторых, создавая методы, которые принимают в качестве параметра родительский экземпляр, но внутри которых вызываются методы дочернего. По ходу текста я упоминал возможные альтернативные реализации – замену наследования на агрегацию, и, универсального рецепта тут нет. В нашей реализации наследование дало нам легкость добавления новых деталей в игру. Например, чтобы добавить новый тип снаряда нам нужно лишь:
Ниже – приведена диаграмма наших классов.
В финальном коде игры все «магические числа», которые использовались в тексте, вынесены в отдельный статический класс Config. К публичным полям статического класса мы можем обратиться из любого фрагмента нашего кода и его экземпляр не нужно (и невозможно) создавать. Вот так он выглядит:
Композиция, агрегация и ассоциация в Java
Изучите свойства и представление композиции, агрегации и ассоциации в Java.
1. введение
Объекты имеют отношения между собой, как в реальной жизни, так и в программировании. Иногда трудно понять или реализовать эти отношения.
В этом уроке мы сосредоточимся на подходе Java к трем иногда легко смешиваемым типам отношений: композиция, агрегация и ассоциация.
2. Состав
В качестве альтернативы, мы часто называем это отношением “имеет-а” (в отличие от отношения “есть-а”, которое является наследованием ).
Например, комната принадлежит зданию, или, другими словами, в здании есть комната. Таким образом, в основном, называем ли мы это “принадлежит” или “имеет”, это только вопрос точки зрения.
Композиция-это сильный вид отношений “имеет-а”, потому что содержащий объект владеет им. Таким образом, жизненные циклы объектов связаны. Это означает, что если мы уничтожим объект-владельца, его члены также будут уничтожены вместе с ним. Например, комната разрушается вместе со зданием в нашем предыдущем примере.
Обратите внимание, что это не означает, что содержащий объект не может существовать без какой-либо из его частей. Например, мы можем снести все стены внутри здания, следовательно, уничтожить комнаты. Но здание все равно будет существовать.
2.1. UML
В UML мы обозначаем композицию следующим символом:
Обратите внимание, что алмаз находится в содержащем его объекте и является основанием линии, а не наконечником стрелы. Для ясности мы тоже часто рисуем наконечник стрелы:
Итак, мы можем использовать эту конструкцию UML для нашего примера здания:
2.2. Исходный код
В Java мы можем смоделировать это с помощью нестатического внутреннего класса:
В качестве альтернативы мы также можем объявить этот класс в теле метода. Не имеет значения, является ли это именованный класс, анонимный класс или лямбда:
Обратите внимание, что очень важно, чтобы наш внутренний класс был нестатическим, поскольку он связывает все свои экземпляры с содержащим классом.
Обычно содержащий объект хочет получить доступ к своим членам. Поэтому мы должны хранить их ссылки:
Обратите внимание, что все внутренние объекты класса хранят неявную ссылку на содержащийся в них объект. В результате нам не нужно хранить его вручную, чтобы получить к нему доступ:
3. Агрегация
Агрегация также является отношением “есть-есть”. Что отличает его от композиции, так это то, что он не предполагает владения. В результате жизненный цикл объектов не привязан: каждый из них может существовать независимо друг от друга.
Например, автомобиль и его колеса. Мы можем снять колеса, и они все еще будут существовать. Мы можем установить другие (уже существующие) колеса или установить их на другой автомобиль, и все будет работать просто отлично.
3.1. UML
Агрегация очень похожа на композицию. Единственное логическое различие заключается в том, что агрегация-это более слабая связь.
Поэтому представления UML также очень похожи. Разница лишь в том, что алмаз пуст:
Тогда для автомобилей и колес мы бы сделали:
3.2. Исходный код
В Java мы можем моделировать агрегацию с помощью простой старой ссылки:
Членом может быть любой тип класса, кроме нестатического внутреннего класса.
В приведенном выше фрагменте кода оба класса имеют свой отдельный исходный файл. Однако мы также можем использовать статический внутренний класс:
Обратите внимание, что Java создаст неявную ссылку только в нестатических внутренних классах. Из-за этого мы должны поддерживать отношения вручную там, где нам это нужно:
4. Ассоциация
Ассоциация означает только то, что объекты “знают” друг друга. Например, мать и ее ребенок.
4.1. UML
В UML мы можем отметить ассоциацию стрелкой:
Если связь двунаправленная, мы можем использовать две стрелки, стрелку с наконечником на обоих концах или линию без наконечников:
Мы можем представить мать и ее ребенка в UML, тогда:
4.2. Исходный код
В Java мы можем моделировать ассоциацию так же, как и агрегацию:
Но подождите, как мы можем определить, означает ли ссылка агрегацию или ассоциацию?
Ну, мы не можем. Разница только логична: является ли один из объектов частью другого или нет.
Кроме того, мы должны поддерживать ссылки вручную на обоих концах, как мы делали с агрегацией:
5. UML Sidenote
Для ясности иногда мы хотим определить мощность отношения на диаграмме UML. Мы можем сделать это, записав его на концах стрелки:
Обратите внимание, что нет смысла писать ноль в качестве мощности, потому что это означает, что нет никакой связи. Единственное исключение-это когда мы хотим использовать диапазон для указания необязательной связи:
Также обратите внимание, что, поскольку в составе есть только один владелец, мы не указываем его на диаграммах.
6. Сложный Пример
Давайте рассмотрим (немного) более сложный пример!
Мы смоделируем университет, в котором есть свои кафедры. На каждой кафедре работают профессора, у которых также есть друзья друг среди друга.
Будут ли кафедры существовать после того, как мы закроем университет? Конечно, нет, поэтому это композиция.
Но профессора все равно будут существовать (надеюсь). Мы должны решить, что более логично: считать ли профессоров частью кафедр или нет. Альтернативно: являются ли они членами департаментов или нет? Да, это так. Следовательно, это агрегация. Кроме того, профессор может работать на нескольких кафедрах.
Отношения между профессорами являются ассоциативными, потому что нет никакого смысла говорить, что профессор является частью другого.
В результате мы можем смоделировать этот пример со следующей диаграммой UML:
И код Java выглядит следующим образом:
7. Заключение
В этой статье мы рассмотрели свойства и представление композиции, агрегации и ассоциации. Мы также видели, как моделировать эти отношения в UML и Java.
Что такое ассоциация и агрегация в Java?
Когда вы пишете программу на Java, если вы хотите связать один класс с другим, используя его ссылку, вы можете использовать Aggregation в Java. Итак, давайте узнаем, как работает агрегация в Java.
Что такое агрегация?
Прежде чем понять, что такое агрегация, давайте узнаем об ассоциации в Java. Ассоциация называется отношением между двумя отдельными классами, которое устанавливается через их Объекты.
Это может быть один к одному, один ко многим, многие к одному, многие ко многим. Давайте разберемся в ассоциациях на примерах.
Вывод: Виан учится в классе Java.
Vian is a student of Java Class.
Теперь давайте посмотрим, что такое агрегация в Java.
Агрегация на самом деле является особой формой ассоциации. Это означает, что это упоминается как отношения между двумя классами, такими как Ассоциация. Тем не менее, это направленная ассоциация, что означает, что она строго следует односторонней ассоциации. Это представляет отношения HAS-A.
Это рассматривается как более специализированная версия отношений Ассоциации. Класс Aggregate содержит ссылку на другой класс и считается владельцем этого класса. Каждый класс, на который есть ссылка, считается частью класса Aggregate.
Теперь, скажем, например, если класс A содержит ссылку на класс B, а класс B содержит ссылку на класс A, то не может быть определено четкое владение, и это просто отношение ассоциации.
Давайте посмотрим на этот пример:
Теперь у вас может возникнуть вопрос: почему должны использовать эту агрегацию в Java?
Зачем нужна?
Основная причина, по которой вам нужна агрегация, заключается в поддержании возможности повторного использования кода. Например, если вы создаете класс, такой же, как в примере выше, вам необходимо сохранить сведения о сотруднике. И вам не нужно снова и снова использовать один и тот же код, а вместо этого использовать ссылку на класс, пока вы его определяете.
