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

Опубликовано

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

Наследование, композиция и агрегация
#include <iostream> #include <string> #include <vector> using namespace.

Наследование vs Композиция vs Агрегация: что лучше выбрать? Как лучше передавать объекты в функции?
Добрый день!! Дело вот в чём, я хочу создать класс, внутри которого будут.

Агрегация ООП
Здравствуйте. Помогите разобраться с одной деталью. Вот код:#include <iostream>.

Агрегация по ссылке
Надо описать наследование классов используя агрегацию по ссылке, текст.

Классы и агрегация
Всем привет. Ребята, может кто дать рабочие примеры агрегации в классах) Буду.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

… не было ни композиции, ни наследования, только код.

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

Основным инструментом для повторного использования кода была копипаста. Процедуры и функции были редкостью, подозрительными новомодными штучками. Вызов процедур был дорогим удовольствием. Части кода, отделенные от основной логики, вызывали недоумение!

Мрачные были времена.

Но вот лучик ООП воссиял над миром… Правда, несколько десятилетий 1 никто этого не замечал. Покуда не появился графический интерфейс 2 , которому, как выяснилось, очень-очень не хватало ООП. Когда нажимаешь на кнопку в окне, что может быть проще, чем отправить кнопке (или ее представителю) сообщение «Нажатие» 3 и получить результат?

И вот тут ООП взлетел. Было написано множество 4 книг, расплодились бесчисленные 5 статьи. Так что сегодня-то каждый может в объектно-ориентированное программирование, так?

Увы, код (и интернет) говорит, что не так

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

Когда мантры вредят

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

Желтушные статьи с заголовками вроде «Наследование — зло» 6 тоже не по мне, особенно если автор пытается обосновать свои набросы, сначала неправильно применяя наследование, а потом делая вывод, что оно во всем виновато. Ну типа «молотки — отстой, потому что ими нельзя завинтить шуруп.»

Далее в статье я буду понимать под ООП «классический» объектный язык, который поддерживает классы со свойствами, методами и простое (одиночное) наследование. Никаких вам интерфейсов, примесей, аспектов, множественного наследования, делегатов, замыканий, лямбд, — ничего, кроме самых простых вещей:

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

Наследование фундаментально

Наследование — это фундаментальное понятие ООП. В языке программирования могут быть объекты и сообщения, но без наследования он не будет объектно-ориентированным (только основанным на объектах, но все еще полиморфным).

… как и композиция

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

(Инкапсуляция тоже вещь фундаментальная, но сейчас речь не о ней)

Так от чего весь сыр-бор?

Ну хорошо, и композиция, и наследование фундаментальны, в чем дело-то?

А дело в том, что можно подумать, что одно всегда может заменить другое, или что первое лучше или хуже второго. Разработка ПО — это всегда выбор разумного баланса, компромисс.

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

Наследование смысловое

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

Наследование механическое

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

Я уверен, что в недопонимании виновата именно эта двойственная природа наследования 7 в большинстве ОО-языков. Многие считают, что наследование — это чтобы повторно использовать код, хотя оно не только для этого. Если придавать повторному использованию чрезмерное значение — жди беды в архитектуре. Вот пара примеров.

Как не надо наследовать. Пример 1

Казалось бы, класс Stack , все хорошо. Но посмотрите внимательно на его интерфейс. Что должно быть в классе с именем Stack? Методы push() и pop() , что же еще. А у нас? У нас есть get() , set() , add() , remove() , clear() и еще куча барахла, доставшегося от ArrayList , которое стеку ну вообще не нужно.

Можно было бы переопределить все нежелательные методы, а некоторые (например, clear() ) даже и адаптировать под наши нужды, но не многовато ли работы из-за одной ошибки в дизайне? На самом деле трех: одной смысловой, одной механической и одной комбинированной:

  1. Утверждение «Stack это ArrayList» ложно. Stack не является подтипом ArrayList . Задача стека — обеспечить выполнение правила LIFO (последним пришел, первым ушел), которое легко удовлетворяется интерфейсом push/pop, но никак не соблюдается интерфейсом ArrayList .
  2. Механически наследование от ArrayList нарушает инкапсуляцию. Клиентскому коду не должно быть известно, что мы решили использовать ArrayList для хранения элементов стека.
  3. Ну и наконец, реализуя стек через ArrayList мы смешиваем две разные предметные области: ArrayList — это коллекция с произвольным доступом, а стек — это понятие из мира очередей, со строго ограниченным (а не произвольным) 8 доступом.

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

Как не надо наследовать. Пример 2

Частая ошибка при наследовании — это создать модель из предметной области, унаследовав ее от готовой реализации. Вот, скажем, нам надо выделить некоторых наших клиентов (класс Customer ) в определенное подмножество. Легко! Наследуемся от ArrayList , называем это CustomerGroup и понеслась.

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

  1. ArrayList это уже наследник списка, утилиты типа «коллекция», готовой реализации.
  2. CustomerGroup это совсем другая штука — класс из предметной области (домена).
  3. Классы из предметной области должны использовать реализации, а не наследовать их.

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

Дело не в одиночном наследовании

Одиночное наследование пока остается самой популярной моделью ООП. Оно неизбежно влечет наследование реализации, которое приводит к сильному зацеплению (coupling — прим. пер.) между классами. Может показаться, что беда в том, что ветка наследования у нас только одна на обе потребности: и смысловую и механическую. Если использовали для одного, то для другого уже нельзя. А раз так, может быть множественное наследование все исправит?

Нет. Отношение наследования не должно пересекать границы между предметными областями: инструментальной (структуры данных, алгоритмы, сети) и прикладной (бизнес-логика). Если CustomerGroup будет наследовать ArrayList и одновременно, скажем, DemographicSegment, то две предметные области переплетутся между собой, а «видовая принадлежность» объектов станет неочевидна.

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

От инструментов можно наследовать только другие инструменты.

Это очень частая ошибка новичков. Что не удивительно, ведь так просто взять и унаследовать. Редко где встретишь обсуждения, почему именно это неправильно. Еще раз: бизнес-сущности должны пользоваться инструментами, а не быть ими. Мухи (инструменты) — отдельно, котлеты (бизнес-модели) — отдельно.

Так когда же нужно наследование?

Наследуемся как надо

Чаще всего — и при этом с наибольшей отдачей — наследование применяют для описания объектов, незначительно отличающихся друг от друга (в оригинале используется термин «differential programming» — прим. пер.) Например, нам нужна особенная кнопка с небольшими дополнениями. Нормально, наследуемся от существующего класса Кнопка. Потому что наш новый класс, это все еще кнопка, а мы полностью наследуем API класса Кнопка, его поведение и реализацию. Новая функциональность только добавляется к существующему. А вот если в наследнике часть функциональности убирается, это повод задуматься, а нужно ли наследование.

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

Композиция или наследование: что выбрать?

В ситуации, когда вроде бы подходит и то и другое, взгляните на дизайн в двух плоскостях:

  1. Структура и механическое исполнение бизнес-объектов.
  2. Что они обозначают по смыслу и как взаимодействуют.

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

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

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

  1. Оба класса из одной предметной области
  2. Наследник является корректным подтипом (в терминах LSP — прим. пер.) предка
  3. Код предка необходим либо хорошо подходит для наследника
  4. Наследник в основном добавляет логику

Иногда все эти условия выполняются одновременно:

  • в случае моделирования высокоуровневой логики из предметной области
  • при разработке библиотек и расширений для них
  • при дифференциальном программировании (автор снова использует термин «differential programming», очевидно, понимая под ним нечто, отличное от DDP — прим. пер.)

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

Надеюсь, эти правила помогут вам понять разницу между двумя подходами.

Отдельная благодарность сотрудникам ThoughtWorks за их ценный вклад и замечания: Питу Хогсону, Тиму Брауну, Скотту Робинсону, Мартину Фаулеру, Минди Ор, Шону Ньюхэму, Сэму Гибсону и Махендре Кария.

Первый официальный ОО-язык, SIMULA 67, появился в 1967 году.

Системные и прикладные программисты приняли на вооружение C++ в середине 1980-х, но перед тем, как ООП стал общепринятым, прошел еще десяток лет.

Я намеренно упрощаю, не говорю про паб/саб, делегатов и тому подобное, чтобы не раздувать статью.

На момент написание этого текста Амазон предлагает 24777 книг по ООП.

Поиск в гугле по фразе «объектно-ориентированное программирование» дает 8 млн результатов.

Поиск в гугле выдает 37600 результатов по запросу «наследование это зло».

Смысл (интерфейс) и механику (исполнение) можно разделить за счет усложнения языка. См. пример из спецификации языка D.

С грустью замечу, что в Java Stack унаследован от Vector .

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

Переводчик выражает благодарность ООП-чату в Telegram, без которого этот текст не смог бы появиться.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь сделаем снаряды – это наиболее очевидный случай для применения наследования, но и агрегацию в нем тоже применим. Любой снаряд имеет свои особенности. Просто неких гипотетических снарядов не бывает. Поэтому класс делаем абстрактным. Делаем ему строковое поле «тип».

Снаряды делают для пушек. Для определенных пушек. Снаряд одного калибра не выстрелит из пушки другого калибра. Поэтому добавляем снаряду поле-ссылку на экземпляр пушки. Делаем конструктор.

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

Конкретные типы снарядов будут наследниками абстрактного снаряда. Наследники могут просто наследовать методы родителя, но могут и быть переопределены, то есть работать не так, как родительский метод. Но мы точно знаем, что любой снаряд должен иметь ряд методов. Любой снаряд должен наносить урон. Метод GetDamage просто возвращает калибр, умноженный на три. В общем случае, урон снаряда зависит от калибра. Но этот метод будет переопределяться в дочерних классах (помним, что снаряды, которые хорошо пробивают броню, как правило наносят меньший «заброневой» урон. Чтобы иметь возможность переопределить метод в дочернем классе, используем слово virtual.

Любой снаряд должен пробивать (или по крайней мере пытаться пробить) броню. В общем случае способность пробивать броню также зависит от калибра (ну, и еще от многого – начальной скорости, например, но мы не будем усложнять). Поэтому, метод возвращает калибр. То есть, грубо говоря, снаряд может пробить броню, равную по толщине своему калибру. Этот метод не будет переопределяться в дочерних классах.

Кроме того, для удобной отладки и организации консольного вывода, имеет смысл добавить метод ToString, который просто позволит нам увидеть, что это за снаряд и какого калибра:

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

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

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

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

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

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

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

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

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

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

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

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

Обратите внимание, что здесь мы снова используем возможности полиморфизма. Наша боекладка вмещает снаряды любого типа, так как список имеет тип данных Ammo – родительский снаряд. Если бы мы не наследовались, а создавали уникальные типы снарядов, пришлось бы делать отдельный список под каждый тип снаряда.

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

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

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

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

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

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

Снова полиморфизм во всей красе. К нам прилетает снаряд. Любой. Исходя из выбранной брони и типа снаряда, вычисляется пробита броня или нет. Если пробита, то вызывается метод конкретного типа снаряда GetDamage().

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

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

  • собственно, скопировать один из существующих типов, заменив название и строковое поле, передаваемое в конструктор;
  • добавить еще один if в дочерние классы брони;
  • добавить дополнительный пункт в меню выбора снаряда в пользовательском интерфейсе.

Аналогично, чтобы добавить еще одну разновидность брони, требуется лишь описать эту разновидность и добавить пункт в пользовательский интерфейс. Модифицировать другие классы или методы не требуется.

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

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

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

Еще по теме: