отношения между классами 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?

Зачем нужна?

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

Источник

Композиция, агрегация и ассоциация в 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.

Источник

Наследование, композиция, агрегация

Нередко случается, что решив разобраться с какой-то новой темой, понятием, инструментом программирования, я читаю одну за другой статьи на различных сайтах в интернете. И, если тема сложная, то эти статьи могут не на шаг не приблизить меня к понимаю. И вдруг встречается статья, которая моментально дает озарение и все паззлы складываются воедино. Трудно определить, что отличает такую статью от других. Правильно подобранные слова, оптимальная логика изложения или же просто более релевантный пример. Я не претендую на то, что моя статься окажется новым словом в C# или же лучшей обучающей статьей. Но, возможно для кого-то она станет именно той, которая позволит разобраться, запомнить и начать правильно применять те понятия, о которых пойдет речь.

В объектно-ориентированных языках программирования существует три способа организации взаимодействия между классами. Наследование — это когда класс-наследник имеет все поля и методы родительского класса, и, как правило, добавляет какой-то новый функционал или/и поля. Наследование описывается словом «является». Легковой автомобиль является автомобилем. Вполне естественно, если он будет его наследником.

Ассоциация – это когда один класс включает в себя другой класс в качестве одного из полей. Ассоциация описывается словом «имеет». Автомобиль имеет двигатель. Вполне естественно, что он не будет являться наследником двигателя (хотя такая архитектура тоже возможна в некоторых ситуациях).

Выделяют два частных случая ассоциации: композицию и агрегацию.

Композиция – это когда двигатель не существует отдельно от автомобиля. Он создается при создании автомобиля и полностью управляется автомобилем. В типичном примере, экземпляр двигателя будет создаваться в конструкторе автомобиля.

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

Хотя ведутся дискуссии о преимуществах того или иного способа организации взаимодействия между классами, какого-либо абстрактного правила не существует. Разработчик выбирает тот или иной путь основываясь на элементарной логике (“является” или “имеет”), но также принимает во внимание возможности и ограничения, которые дают и накладывают эти способы. Для того, чтобы увидеть эти возможности и ограничения, я попытался написать пример. Достаточно простой, чтобы код оставался компактным, но и достаточно развитый, чтобы в рамках одной программы можно было применить все три способа. И, главное, я попытался сделать этот пример как можно менее абстрактным – все объекты и экземпляры понятны и осязаемы.

Напишем простенькую игру – танковый бой. Играют два танка. Они поочередно стреляют и проигрывает тот, здоровье которого упало до нуля. В игре будут различные типы снарядов и брони. Для того, чтобы нанести урон необходимо во-первых, попасть по танку противника, во-вторых, пробить его броню. Если броня не пробита, урон не наносится. Логика игры построена на принципе «камень-ножницы-бумага»: то есть броня одного типа хорошо противостоит снарядам определенного типа, но плохо держит другие снаряды. Кроме того, снаряды, которые хорошо пробивают броню, наносят малый «заброневой» урон, и, напротив, наиболее «летальные» снаряды имеют меньше шансов пробить броню.

Создадим простенький класс для пушки. Он будет иметь два приватных поля: калибр и длину ствола. От калибра зависит урон, и, частично, способность к пробитию брони. От длины ствола – точность стрельбы.

Сделаем также конструктор для пушки:

Сделаем метод для получения калибра из других классов:

Помните, что для поражения цели должно произойти две вещи: попадание в цель и пробитие брони? Так вот, пушка будет отвечать за первую из них: попадание. Поэтому делаем булевый метод IsOnTarget, который принимает случайную величину (dice) и возвращает результат: попали или нет:

Целиком класс пушки выглядит следующим образом:

Здесь мы применили агрегацию. Где-то будет создана пушка. Потом к этой пушке будут создаваться снаряды, которые имеют указатель на пушку.

Теперь сделаем разные типы снарядов, которые будут наследовать абстрактный снаряд: фугасный, кумулятивный, подкалиберный. Фугасный наносит самый большой урон, кумулятивный – меньше, подкалиберный – еще меньше. Дочерние классы не имеют полей и вызывают конструктор базового снаряда, передавая ему пушку, и строковый тип. В дочернем классе переопределяется метод GetDamage() – вносятся коэффициенты, которые увеличат или уменьшат урон по сравнению с дефолтным.

Фугасный (дефолтный урон):

Кумулятивный (дефолтный урон х 0.6):

Подкалиберный (дефолтный урон х 0.3):

Обратите внимание, что в переопределенном методе GetDamage вызывается и метод базового класса. То есть, переопределив метод, мы также сохраняем возможность обратиться к дефолтному методу, использовав ключевое слово base).

Итак, для снарядов мы применили и агрегацию (пушка в базовом классе), и наследование.
Создадим теперь броню для танка. Здесь применим только наследование. Любая броня имеет толщину. Поэтому абстрактный класс брони будет иметь поле thickness, и строковое поле type, которое будет определятся при создании дочерних классов.

Броня будет в нашей игре определять пробита они или нет. Поэтому, у нее будет лишь один метод, который будет переопределяться в дочерних, в зависимости от типа брони.

Для того, чтобы конструктор танка остался более-менее компактным, сделаем два вспомогательных приватных метода, которые добавляют три типа брони соответствующей толщины, и наполняют боеукладку 10 снарядами каждого из трех типов:

Теперь конструктор танка выглядит вот таким образом:

Пользовательский интерфейс танка состоит из трех методов: выбрать броню, зарядить пушку, выстрелить.

Как я упомянул в начале, в этом примере я старался максимально уйти от абстрактных понятий, которые нужно все время держать в голове. Поэтому каждый экземпляр снаряда у нас равен физическому снаряду, который положили в боеукладку перед боем. Следовательно, снаряды могут закончится в самый неподходящий момент!

Этот интерфейс требует реализации метода Clone(). Вот она:

Теперь все супер реалистично: при выстреле генерируется dice, пушка рассчитывает попадание своим методом IsOnTarget, и, если попадание есть, то метод Shoot вернет экземпляр снаряда, а если промах – то вернет null.

Последний метод танка – его поведение при попадании вражеского снаряда:

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

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

Ниже – приведена диаграмма наших классов.

В финальном коде игры все «магические числа», которые использовались в тексте, вынесены в отдельный статический класс Config. К публичным полям статического класса мы можем обратиться из любого фрагмента нашего кода и его экземпляр не нужно (и невозможно) создавать. Вот так он выглядит:

Источник

BestProg

Содержание

Поиск на других ресурсах:

1. Каким образом повторное использование кода применяется в классах?

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

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

2. Какие существуют способы (подходы) построения классов для эффективного обеспечения повторного использования кода?

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

В объектно-ориентированных языках программирования (Java, C++, C# и прочих) существуют три способа построения классов, которые повторно используют программный код:

Эти способы еще называют отношениями между классами. Во всех способах строятся новые классы (типы) на базе уже существующих классов (типов).

3. Примеры композиции в классах

4. Какая общая форма простейшего наследования классом другого класса. Ключевое слово extends

5. Примеры наследования в классах

6. Пример объединения композиции и наследования

На примере объявления трех классов демонстрируется объединение композиции и наследования.

Рисунок. Схема объединения композиции и наследования для трех классов

Исходный код модуля с разработанными классами.

7. Особенности делегирования по сравнению с наследованием и композицией. Пример

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

После такого переопределения обращение к методу MethodA() класса B будет выглядеть так если бы MethodA() был унаследован:

Такая организация отношения между классами называется делегированием. Метод MethodA() класса B называется делегированным методом.

8. Какие отличия между композицией и наследованием?

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

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

Наследование позволяет расширять возможности нового класса с точки зрения его специализации. Это значит, что создается специализированная версия уже существующего класса. То есть, берется уже существующий класс (базовый класс) и создается его новая специализированная версия. Как правило, в роли базового класса выступает некий класс общего назначения, в котором выделены общие черты задачи. Наследованием выражает взаимосвязь is-a («есть» или «является»).

Композиция используется, когда нужно использовать функциональность уже существующего класса в другом (новосозданном) классе. В этом случае в новосозданном классе объявляется объект класса, функциональность которого нужно использовать. Композиция является одним из видов взаимосвязи has-a (клас «содержит»).

Объект класса в другом классе может быть скрытым ( private ), открытым ( public ) или защищенным ( protected ).

Источник

Просто о композиции, агрегации и ассоциации в JavaScript

Данная небольшая заметка о типах отношений между объектами в ООП. Можно использовать как шпаргалку, если кто знал, но подзабыл или, если для кого эти термины будут в новинку используйте как первый шаг в изучение основ ООП.

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

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

Самый простой способ понять эти термины это использовать аналогию из реального мира. Представим себе что у нас есть класс комната и есть два других класса мебель и стена. Мы можем сказать что у комнаты будет какая та мебель и какие то стены. То есть объект комната может использоваться объекты стены и мебель по мере необходимости. Но есть разница в отношения комната — стены и комната — мебель. Разница в том что стены никогда не выйдут из объекта комната. Стены не могут существовать вне комнаты. То есть стена всегда будет создаваться внутри объекта комната. Такая связь называется композиция. И эта связь будет жесткой. Зато мебель очень легко представить за пределами комнаты. Один экземпляр мебели может принадлежать с начало одной комнате потом другой. Такая связь называется ассоциацией или агрегацией. И такая связь будет более гибкой. О различие между ассоциацией или агрегацией чуть позже.

Рассмотрим эти связи подробнее.

Ассоциация

Ассоциация это такой тип при котором объекты будут ссылаться друг на друга. При этом они остаются полностью независимыми друг от друга.

Пример реализации ассоциации

Тут у нас есть атрибут stream, в котором должна быть ссылка на поток который куда то будет отправлять сообщение. Метод log проверяет что в классе задан stream и использует его для отправки сообщения. То есть ассоциация это когда у одного класса есть ссылка на другой класс. Это создает большую гибкость в отношениях между классами. Например у нас есть возможность смены потока во время выполнения программы.

Агрегация

Агрегация это тип отношений когда один объект является частью другого. Агрегация образует слабую связь между объектами. Все зависимые классы инициализируются вне основного объекта.

Пример реализации агрегации:

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

Композиция

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

Пример реализации композиции

В данном случае внутри конструктора создается экземпляр другого класса. При этом создается более крепкая связанность этих двух классов. То есть класс Logger обязательно знает что существует библиотека fs, у него есть класс fs и у него есть метод createWriteStream и т. д. Он полностью знает реализацию другого класса.

То есть в ассоциации и агрегации предполагалось что эти два класса создается независимо, а потом связываются ссылками, в композиции они создается вместе в момент вызова конструктора.

Источник