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

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

На диаграмме два класса связаны с друг другом связь агрегат. Поясните пожалуйста:

  1. Почему агрегатом связывают два класса?
  2. Что означает стрелка на линии связи, направленная на класс «Видимость»?
  3. Что означает цифры 0..3 рядом с классом «видимость»? Это типа «Видимость» можно создать в количестве о или 3?

Для начала определимся:

  1. Целая часть — это Наблюдения за погодой
  2. Составная часть — это Видимость

Разница между агрегацией и композицией

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

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

Читаем вашу диаграмму

Целая часть «Наблюдения за погодой» имеет (has a) внутри себя составную часть «Видимость» (стрелочка с ромбиком), общее количество которых может быть в интервале от 0 до 3 (цифры над составной частью).

На основе этого вы можете написать программный код.

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

Объясните по-человечески, желательно на примере, в чём заключается разница между композицией и наследованием? Читаю Философия Java Эккеля, застрял на этой теме, объясняется все вроде бы хорошо, но я не понял.

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

Итак, какие же преимущества есть у композиции перед наследованием?

  1. Нет конфликта имён, возможного при наследовании.
  2. Возможность смены агрегируемого объекта в runtime.
  3. Полная замена агрегируемого объекта в классах, производных от класса, включающего агрегируемый объект.

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

Если рассматривать, например, C#, не поддерживающий множественное наследование, но позволяющий наследовать от множества интерфейсов и создавать методы расширения для этих интерфейсов, то можно выделить ещё два плюса (речь в данном случае может идти только о поведениях (алгоритмах) в рамках паттерна «Стратегия»): 4. Агрегируемое поведение (алгоритм) может включать в себя другие объекты. Что в частности позволяет переиспользовать посредством агрегации другое поведение. 5. При агрегации есть возможность скрыть определённую часть реализации, а также исходные параметры, необходимые поведению, посредством передачи их через конструктор (при наследовании поведению придётся запрашивать их через методы/свойства собственного интерфейса).

Но как же минусы? Неужели их нет?

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

Разрешить эту ситуацию можно, запретив установку поведения извне или доверив его, например, generic-методу: void SetBehavior() запретив тем самым создание поведения кем-либо, кроме объекта-владельца. Однако мы не можем запретить использовать поведение «где-то ещё». В языках без сборщика мусора (GC) это порождает понятные проблемы. Конечно, в таких языках можно неправомерно обратиться по ссылке и на сам объект-владелец, но, раздавая отделённые объекты поведения направо и налево, мы получаем в разы больше шансов получить exception.

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

В таком случае, нам придётся или передавать в такой код нетипизированный объект (как object или void*), или создавать дополнительный интерфейс для объекта-владельца (некий IBehaviorOwner), или хранить в поведении циклическую ссылку на объект-владелец. Понятно, что каждый из этих вариантов имеет свои минусы и ещё больше усложняет код. Более того, различные типы поведений могут зависеть друг от друга (и в это вполне допустимо, особенно если они находятся в некоем закрытом самодостаточном модуле).

  1. Ну и последний минус — это конечно же производительность. Если объектов-владельцев достаточно много, то создание и уничтожение вместо одного объекта двух или более может не остаться незамеченным.

Получается, что утверждение «композиция всегда лучше наследования» в ряде случаев спорно и не должно являться догмой. Особенно это касается языков, позволяющих множественное наследование и не имеющих GC. Если в какой-либо ситуации перечисленные выше плюсы не важны, и заранее известно, что при работе с определёнными типами у вас не будет возможности их использовать, стоит всё-таки рассмотреть вариант наследования.

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

Проектирую доменную область сервиса для тестирования. В различных тестированиях будут принимать участие различные категории участников: ученик школы, учитель школы и бывший ученик школы, который является бывшим учеником данной школы. Необходимо отметить, что бывший ученик школы при тестировании привязывается в целом к школе, класса у него нет (он ведь уже отучился).

В сети часто можно встреть утверждение, что необходимо по возможности использовать композицию нежели наследование. Но также есть другое утверждение, с которым я больше согласен и это: необходимо просто понять какая из двух связей существует is (наследование) или has (композиция/агрегация).

Вопрос в целом звучит так:

1. Правильно ли я сделал, в первую очередь с концептуальной точки зрение, что выбрал тут наследование, а не композицию?

А подвопрос такой:

1.1) Эти сущности будут проецироваться на таблицу реляционной базы данных и мне необходимы поля AddedDate — время добавления записи и DataSourceName — наименование источника данных (при добавлении через ЛК это будет название логина). Но с концептуальной точки зрения разве правильно звучит утверждение «Я участник тестирования и у меня есть свойство «ВремяДобавленияМеняВбазуДанных»»? Разве можно подобные свойства ставить на ряду с такими как Фамилия и Имя. Быть может тут какой-то паттерн необходим? Каких знаний в проектировании мне не хватает?

Читайте так же:  Страховая компания росгосстрах екатеринбург отзывы по осаго

1) Если говорить о сигнальных английских глаголах связанных с отношениями между классами, то Composition — это has a . , а вот Aggregation — это part of . .

2) Надо отдавать себе отчет в том, что совет отдавать предпочтение композиции перед наследованием вполне себе оправдан из-за того, что зачастую программист начинает построение иерархической системы из классов, которая порой ничем не оправдана кроме как желанием поменьше написать повторяющихся названий свойств, например «. О! Id — создам-ка я класс Entity . » и так далее. В результате такого подхода возникает иерархическая система из классов, которая в принципе может быть не нужна в приложении, а может даже и очень сильно мешать в дальнейшем. К наследованию лучше прибегать в случае если вы начинаете проектирование с абстракций, т.е. начинаете программировать с интерфейсов и абстрактных классов, хотя в случае интерфейсов наследование называется реализацией, но вы меня понимаете.

3) Конкретно в вашем случае, на мой скромный взгляд, у вас есть сущности: Человек , Опыт и связанная с ним ТипОпыта — это буквально словарные названия (Ученик, Учитель и т.д.), которые хранятся в отдельной таблице БД. Сущность Опыт должна иметь соотв. свойства (ДатаНачала, ДатаОкончания, ТипОпыта, Стаж, ну и проч. что надо), таким образом по таблице Опыт в БД можно отследить весь учебный и трудовой путь нужного человека.

А вот это ваше наследование никуда не годится.

4) «. AddedDate — время добавления записи и DataSourceName — наименование источника данных. » такие вещи выносят в отдельные таблицы в БД с отношением «один-к-одному». Т.е. есть таблица «Человек» а к ней «прицепом» отдельная таблица «ЧеловекСекретное», в которой будут хранится логин, пароль и проч. служебная инфа.

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

Подскажите, пожалуйста, в чем разница между черным и белыми ромбами при наследовании класса в диаграммах UML?

Незакрашенный ромб — отношение аггрегации. Агрегация — это отношение целое часть.

  • агрегат ( MyEntityClass ) может существовать как независимо от частей ( MyClass ), так и вместе с ними;
  • части могут существовать независимо от агрегата
  • агрегат является в некотором смысле неполным в случае отсутствия частей
  • части могут принадлежать одновременно нескольким агрегатам

Закрашенный ромб — композиция. Композиция — это строгая форма агрегации.

  • Одновременно части ( MyClass2 ) могут принадлежать только одному композиту ( MyEntityClass ) — совместное владение частями невозможно.
  • композит обладает исключительной ответственностью за все свои части; это значит что он отвечает за их создание и уничтожение
  • композит может высвобождать части, передавая ответственность за них другому объекту
  • в случае уничтожения композита он должен уничтожить все свои части или передать ответственность за них другому объекту.

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

Читайте так же:  Судебные приставы черемушкинский

Д. Арлоу, А. Нейштадт — «UML2 и унифицированный процесс»

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

Агрегация и композиция. C#

Агрегация и композиция

В предыдущей статье я рассказывал о том, как можно заменить наследование используя композицию, если главное что Вам нужно — это избежать повторного написания некого кода. К примеру, Вам доступен какой-то класс (причем, его разработчиком можете быть даже не Вы), функциональность которого Вы хотите расширить. Вы можете написать класс-наследник (если исходный класс не помечен как sealed, о том что такое sealed-классы, я рассказывал в этой статье), получив при этом ряд «побочек», или воспользоваться принципом композиции. Но не одной композицией можно решать подобные проблемы. Есть еще так называемая агрегация. И в этой статье, я хочу вкратце рассказать о том, что же такое агрегация и в чем её отличие от композиции.

И так, скажу сразу, что агрегация и композиция очень близкие понятия! В обоих случаях есть объемлющий объект (объект-контейнер, если хотите) и объект-содержимое (этого контейнера). Объект-содержимое, как привило является полем объекта-контейнера. Но в тоже время, между композицией и агрегацией есть одно важное отличие: при использовании композиции, объект-содержимое не может существовать без своего контейнера, а случае агрегации, такое вполне возможно. Да еще и при использовании агрегации, объект-содержимое может принадлежать даже нескольким контейнерам (но тут нужно быть осторожным) или у одного объекта-контейнера, в течении «жизни», может быть разное содержимое (причем, агрегация позволяет использовать даже содержимое разных типов одном у тому же контейнеру).

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

А теперь, я покажу как на практике выглядит агрегирование (использование композиции я показывал в предыдущей статье, ссылку на которую приводил выше):

Как можно заметить, в отличии от композиции, в данном примере, мы не создаем объект типа «Sender» внутри класса «SenderM». Такой объект будет создаваться за пределами класса, а конструктор типа «SenderM» будет принимать ссылку на этот объект. Вот в этом и есть главное отличие агрегирования от композиции.

Как видите, использовать такие классы тоже несложно…

Добавить комментарий Отменить ответ

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

ООП (Агрегация и Композиция)

Доброго времени суток.

Стараюсь глубже понять основные принципы ООП, прочитал теорию про композиционный подход при проектировании класса,
но очень хочется увидеть простой пример — иллюстрацию на делфи (Композиция) и
простой пример — иллюстрацию на делфи (Агрегация)

много примеров для других ЯП , но хочется посмотреть как это на делфи делается (особенно хорошо если
будет показана некоторая типичная задача когда композиция лучше Наследования).
Еще интересует такой момент можно ли сочетать одновременно и Наследование и Композицию.

Композиция, агрегация и абстракция

Абстракция
Есть абстрактный класс, есть классы-наследники, реализующие методы абстрактного.

Абстракция, уровни абстракции
Как понять это? Может кто-нибудь объяснить более доступным и понятным языком.

Зачем нужна абстракция?
Знаю что она определяет некий список параметров, методов. Но зачем это все.

Абстракция «сокрытие информации»?
Всем привет, смотрю курс по c# , и вот на одном из уроков посвященному.

Агрегация в C#
Объясните пожалуйста, что такое агрегация на каком-нибудь примере.