Какое свойство строит иерархию объектов
Аннотация: Описание потомков объекта. Наследование полей и методов. Раннее и
позднее связывание. Механизм виртуальных методов. Конструкторы и деструкторы.
Размещение объектов в динамической памяти. Полиморфные объекты. Контейнер
(список) полиморфных объектов.
Наследование
Презентацию к данной работе Вы можете скачать здесь.
Управлять большим количеством разрозненных объектов достаточно сложно. С этой проблемой можно справиться путем упорядочивания и ранжирования объектов, то есть объединяя общие для нескольких объектов свойства в одном объекте и используя этот объект в качестве базового.
Эту возможность предоставляет механизм наследования. Он позволяет строить иерархии, в которых объекты-потомки получают свойства объектов-предков и могут дополнять их или изменять. Таким образом, наследование обеспечивает возможность повторного использования кода.
Объекты, расположенные ближе к началу иерархии, объединяют в себе наиболее общие черты для всех нижележащих объектов. По мере продвижения вниз по иерархии объекты приобретают все больше конкретных особенностей.
Объект в Паскале может иметь произвольное количество потомков и только одного предка. При описании объекта имя его предка записывается в круглых скобках после ключевого слова object.
Допустим, нам требуется ввести в игру еще один тип персонажей, который должен обладать свойствами объекта monster, но по-другому выглядеть и атаковать. Будет логично сделать новый объект потомком объекта monster. Проанализировав код методов этого объекта, переопределим только те, которые реализуются по-другому (
пример
7.1).
procedure init(x_, y_, health_, ammo_, magic_ : word);
procedure attack;
procedure draw;
procedure erase;
procedure wizardry;
private
magic : word;
end;
{ ————————- реализация методов объекта daemon —————– }
procedure daemon.init(x_, y_, health_, ammo_, magic_ : word);
begin
inherited init(x_, y_, health_, ammo_);
color := green;
magic := magic_;
end;
procedure daemon.attack; { ——————————— daemon.attack —- }
begin
if ammo = 0 then exit;
dec(ammo);
if magic > 0 then begin
outtextXY(x + 15, y, ‘БУ-БУХ!’); dec(magic); end
else
outtextXY(x + 15, y, ‘бу-бух!’);
end;
procedure daemon.draw; { ———————————– daemon.draw —- }
begin
setcolor(color); outtextXY(x, y, ‘%)’);
end;
procedure daemon.erase; { ———————————– daemon.erase —- }
begin
setcolor(black); outtextXY(x, y, ‘%)’);
end;
procedure daemon.wizardry; { ——————————– daemon.wizardry – }
begin
if magic = 0 then exit;
outtextXY(x + 15, y, ‘крибле-крабле-бумс!’); dec(magic);
end;
Листинг
7.1.
Переопределение методов после добавления нового типа персонажей
Наследование полей.Унаследованные поля доступны в объекте точно так же, как и его собственные. Изменить или удалить поле при наследовании нельзя.Объект daemon содержит все поля своего предка и одно собственное поле magic, в котором хранится “магическая сила” объекта.
Наследование методов.В потомке объекта можно не только описывать новые методы, но и переопределять существующие. Метод можно переопределить либо полностью, либо дополнив метод предка.
В объекте daemon описан новый метод wizardry, с помощью которого объект применяет свою магическую силу, а метод инициализации init переопределен, потому что количество полей объекта изменилось. Однако необходимость задавать значения унаследованным полям осталась, и соответствующий метод есть в объекте monster, поэтому из нового метода инициализации сначала вызывается старый, а затем выполняются дополнительные действия (присваивание значения полю ammo ).
Вызов метода предка из метода потомка выполняется с помощью ключевого слова inherited (унаследованный). Можно вызвать метод предка и явным образом с помощью конструкции monster.init.
Методы отрисовки draw и erase также переопределены, потому что изображение демона отличается от изображения монстра и, следовательно, формируется другой последовательностью подпрограмм (для простоты представим демона в виде “смайлика”).
Переопределен и метод attack: теперь атака выполняется по-разному в зависимости от наличия магической силы.
Чтобы перемещать демона, требуется выполнить те же действия, что записаны в методе move для перемещения монстра: необходимо стереть его изображение на старом месте, обновить координаты и нарисовать на новом месте. На первый взгляд, можно без проблем унаследовать этот метод, а также метод hit. Так мы и поступим.
Добавим описание объекта daemon в интерфейсную часть модуля monsters, а тексты его методов — в раздел реализации. Проверим работу новых методов с помощью программы:
uses graph, crt, monsters;
var Vasia : daemon;
gd, gm : integer;
begin
gd := detect; initgraph(gd, gm, ‘…’);
if graphresult <> grOk then begin
writeln(‘ошибка инициализации графики’); exit end;
Vasia.init(100, 100, 20, 10, 6);
Vasia.draw; Vasia.attack;
readln;
Vasia.erase;
readln;
end.
И в предке, и в потомке есть одноименные методы. Вызывается всегда тот метод,
который соответствует типу объекта, потому что при вызове указывается
имя экземпляра заданного типа (
рис.
7.1). Это можно
рассматривать как простейший вид полиморфизма.
Рис.
7.1.
Раннее связывание
Источник
Аннотация: Структура объектов JavaScript, порядок их подчинения.
Концепция
Сделаем паузу и посмотрим, что мы уже знаем. В JavaScript есть объекты, похожие на существительные или предметы. У объектов есть свойства, которые описывают их, как прилагательные описывают существительное. Мы ссылаемся на свойства с помощью схемы oбъект.свойство.
Еще у объектов есть методы, или действия, которые можно выполнить с объектом. Все методы имеют скобки и используются по схеме oбъект.мeтoд(). У разных объектов имеются разные свойства и методы.
Теперь мы познакомимся с иерархией объектов JavaScript. Как только вы ее поймете, cчитайте, что вы освоили JavaScript!
Что имеется в виду
- Window
- Parent
- Self
- Location
- Href
- Document
- Image
- Src
- Form
- Text
- Submit
- Checkbox
- Image
- Location
- Top
- Frames
Результат действия иерархии
Все ссылки начинаются с наивысшего объекта, window (окно браузера), и идут по нисходящей. Окна и рамки (frames) принадлежат объекту window. На них не нужно ссылаться, если только их не больше одного. Top, self, parent и frames — “встроенные” имена для окон. Не придавайте им большого значения, просто знайте, что они существуют.
Вот несколько примеров. Обратите внимание на иерархию.
в самом начале window не требуется. Предполагается, что это все и так находится внутри окна. Команда document.mypic.src указывает на изображение с именем mypic, и изменяет его содержимое на “pic1.gif”. В данном случае document (документ) — это страница на которой находится элемент, mypic — имя элемента, а SRC — источник элемента ( “pic1.gif” ).
write() — это метод объекта document. location.href содержит полный URL окна. Обратите внимание, что location и dосument находятся на одном уровне. Это значит, что вы получаете адрес документа того же уровня.
Разбор иерархии объектов
- Window
- Parent
- Self
- Location
- Href
- Document
- Image
- Src
- Form
- Text
- Submit
- Checkbox
- Image
- Location
- Top
- Frames
- Самая большая путаница в том, что некоторые объекты также являются и свойствами.
- window — только объект.
- document является свойством окна, но в свою очередь и объектом.
- form — это свойство документа, но также и объект со своими свойствами!
- value (значение) и SRC (источник) — только свойства!
- Здесь представлены не все объекты и свойства. Однако этого достаточно, чтобы понять концепцию в целом… Все ссылки начинаются сверху от window и идут по нисходящей. То есть, нельзя написать document.mytext.myform или mypic.src.document. Это неправильный порядок, следует писать слева направо от более общего к более конкретному.
- Важное замечание: чтобы показать содержимое поля формы, необходимо использовать свойство value (значение), например, document.myform.mytext.value! Если написать просто document.myform.mytext, то будет получена информация о поле формы, но не о его содержании!
Считайте value (“значение”) некоторым показателем того, что нечто имеется или отсутствует в определенное время. Поле с флажком может иметь значение “on” или “off”, в зависимости от того, задан он или нет. Текстовое поле может иметь значение “hidden” (скрытое), если вы не хотите, чтобы пользователь его видел. Текстовое поле, как указано выше, может содержать какую-то запись. Она будет значением этого поля.
Задание
Напишите полные ссылки, начиная с window, даже если это не требуется. Обратите внимание, что изображение имеет имя mypic, а форма — myform.
- Ссылка на всю форму:
- Ссылка на содержимое поля lname:
- Ссылка на содержимое поля fname:
- Замените изображение на “marigold.gif”:
Ответы
- window.document.myform
- window.document.myform.lname.value
- window.document.myform.fname.value
- window.document.mypic.src=marigold.gif
Источник
Иерархия объектов очень удобна когда нам нужно задать какие-то трансформации объектов не относительно начала координат, а относительно друг-друга. Например, если создать иерархию из двух объектов: рука и туловище, то для того, что бы рука двигалась вместе с туловищем, нам не надо будет прилагать каких-либо усилий – при движении туловища трансформации всех объектов в иерархии (в нашем случае рука) будут пересчитаны в соответствии с движением объектов привязки (в нашем случае туловища), но при этом сами объекты могут трансформироваться относительно своего “предка” в иерархии. Чаще всего иерархии объектов применяются для создания и анимации механизированных агрегатов, таких как “механические руки”, подъёмные краны, двери (да-да, двери это наиболее частое применение иерархий объектов), разного рода выдвигающиеся откуда-то лестницы и многое другое. Все эти элементы игрового мира в большинстве случаев реализованы именно иерархиями объектов.
Реализация иерархии объектов
Реализация иерархии объектов достаточно проста. По большей части всё, что нам нужно сделать, это реализовать механизм наследования трансформаций от одного объекта к другому (или нескольким). Для этого каждый объект должен иметь собственную матрицу трансформации и, если для него задан “родительский” объект, он должен так же наследовать трансформацию согласно иерархии от этого родительского объекта. Для этого я дслелал отдельный класс, который назвал CEntity. Этот класс содержит в себе только информацию о положении и трансформации объекта (т.е. матрицу трансформации – она задаёт и положение и трансформацию), а так же информацию о “предке”, от которого, по иерархии, будут наследоваться трансформации объектов:
class CEntity
{
private:
CEntity* m_pParent;
D3DXMATRIXA16 m_matrix;
public:
CEntity(void);
virtual ~CEntity(void);
const D3DXMATRIX GetMatrix() const;
D3DXVECTOR3 GetPos() const;
void SetMatrix(const D3DXMATRIX& mat);
void SetRotation(const D3DXMATRIX& mat);
void SetPos(const D3DXVECTOR3& pos);
void SetParent(CEntity* pParent);
};
Как видите, тут нет ничего, кроме предка и матрицы трансформации, а та же всего нескольких функций, которые позволяют задать текущие трансформации и/или получить их.
Иерархии объектов из 3д-моделей
Для задания иерархий моделей я сделал отдельный класс. Сделал я это потому как считаю, что такие элементы, как иерархические модели, используются достаточно часто и такой код поможет нам в будущем сэкономить ещё немного времени на том, что мы не будем постоянно писать один и тот же код для разных иерархий и моделей:
class CEntityModel :
public CEntity
{
private:
CMeshPtr m_pMesh;
public:
CEntityModel(const std::string& strFileName=””);
virtual ~CEntityModel(void);
bool SetModel(const std::string& strFileName);
void ReleaseModel();
CMeshPtr GetMesh() const;
};
Наследования трансформаций в иерархии объектов
Само наследование трансформаций внутри иерархии объектов так же делается элементрно. Реализован этот функционал в одной из функций представленного выше класса:
{
if (!m_pParent)
{
return m_matrix;
}
D3DXMATRIXA16 m = m_pParent->GetMatrix();
D3DXMatrixMultiply(&m, &m_matrix, &m);
return m;
}
Как видите, всё гениальное просто )))
Хочу заметить, что в данный момент я не ставлю перед собой цели как-то оптимизировать код – для наших с Вами целей быстродействие нашей программы и так будет более, чем достаточным.
Настройка иерархии объектов
Я не стал изголяться с конфигами и прочим и задал саму иерархию и зависимости объектов в самой программе – наш пример программы достаточно простой, потому сделать это оказалось совсем не сложно – я просто указал для каждого их объектов его положение (относительно предка) и задал самих предков ещё на этапе инициализации приложения:
m_modelMiddle.SetModel(“Data/middle.GAMEMODEL”);
m_modelBottom.SetModel(“Data/bottom.GAMEMODEL”);
m_modelTop.SetPos(D3DXVECTOR3(0, 16, 0));
m_modelMiddle.SetPos(D3DXVECTOR3(0, 15, 0));
m_modelBottom.SetPos(D3DXVECTOR3(0, 0, 0));
m_modelMiddle.SetParent(&m_modelBottom);
m_modelTop.SetParent(&m_modelMiddle);
Анимация иерархических объектов
Поскольку внутри иерархии объекты наследуют трансформации, анимировать иерархии получается очень просто, даже проще, чем можно было себе представить… Тем более, что как раз для апдейта сцены у нас в классе CGameApplication предусмотрена отдельная функция под названием UpdateFrame(), то как раз её я и использовал:
{
D3DXMATRIX m;
static float a=0.0f;
a+=.03f;
D3DXMatrixRotationZ(&m, -cos(a) + cos(a*3)*.2f);
m_modelTop.SetRotation(m);
D3DXMatrixRotationZ(&m, cos(a));
m_modelMiddle.SetRotation(m);
}
После чего всё заработало само-собой…
На этом я пока хочу закончить с разговором о иерархиях объектов. Думаю, исходный код, а так же готовая дема, помогут Вам разобраться что к чему. Если же нет – я, как обычно, жду ваших комментариев и постараюсь объяснить все непонятные или плохо мной раскрытые моменты…
Ещё по этой теме:
Источник
Принципы
объектно-ориентированного представления программных систем
Рассмотрение любой
сложной системы требует применения техники декомпозиции — разбиения на
составляющие элементы. Известны две схемы декомпозиции: алгоритмическая
декомпозиция и объектно-ориентированная декомпозиция.
В основе
алгоритмической декомпозиции лежит разбиение по действиям — алгоритмам. Эта
схема представления применяется в обычных ПС.
Объектно-ориентированная
декомпозиция обеспечивает разбиение по автономным лицам — объектам реального
(или виртуального) мира.
•
Эти лица (объекты) — более «крупные» элементы,
каждый из них несет в себе и описания действий, и описания данных.
•
Объектно-ориентированное представление ПС
основывается на принципах абстрагирования, инкапсуляции, модульности и
иерархической организации. Каждый из этих принципов не нов, но их совместное
применение рассчитано на проведение объектно-ориентированной декомпозиции. Это
определяет модификацию их содержания и механизмов взаимодействия друг с другом.
Абстрагирование
Аппарат абстракции —
удобный инструмент для борьбы со сложностью реальных систем. Создавая понятие в
интересах какой-либо задачи, мы отвлекаемся (абстрагируемся) от несущественных
характеристик конкретных объектов, определяя только существенные характеристики.
Например, в абстракции «часы» мы выделяем характеристику «показывать время»,
отвлекаясь от таких характеристик конкретных часов, как форма, цвет, материал,
цена, изготовитель.
Итак, абстрагирование
сводится к формированию абстракций. Каждая абстракция фиксирует основные
характеристики объекта, которые отличают его от других видов объектов и
обеспечивают ясные понятийные границы.
Абстракция
концентрирует внимание на внешнем представлении объекта, позволяет отделить
основное в поведении объекта.от его реализации. Абстракцию удобно строить путем
выделения обязанностей объекта.
Модульность
Модули служат
физическими контейнерами, в которых объявляются классы и объекты логической
разработки.
Модульность определяет
способность системы подвергаться декомпозиции на ряд сильно связанных и слабо
сцепленных модулей.
Общая цель
декомпозиции на модули: уменьшение сроков разработки и стоимости ПС за счет
выделения модулей, которые проектируются и изменяются независимо. Каждая модульная
структура должна быть достаточно простой, чтобы быть полностью понятой.
Изменение реализации модулей должно проводиться без знания реализации других
модулей и без влияния на их поведение.
Иерархическая
организация
Иерархическая организация
— формирование из абстракций иерархической структуры. Определением иерархии в
проекте упрощаются понимание проблем заказчика и их реализация — сложная
система становится обозримой человеком.
Иерархическая
организация задает размещение абстракций на различных уровнях описания системы.
Двумя важными
инструментами иерархической организации в объектно-ориентированных системах
являются:
структура из классов («is a»-иерархия);
структура из объектов («part of»-иерархия).
Чаще всего «is а»-иерархическая структура
строится с помощью наследования. Наследование определяет отношение между
классами, где класс разделяет структуру или поведение, определенные в одном
другом (единичное наследование) или в нескольких других (множественное
наследование) классах.
Другая разновидность
иерархической организации — «part of»-иерархическая
структура — базируется на отношении агрегации. Агрегация не является понятием,
уникальным для объектно-ориентированных систем. Например, любой язык
программирования, разрешающий структуры типа «запись», поддерживает агрегацию.
И все же агрегация особенно полезна в сочетании с наследованием:
1.
агрегация обеспечивает физическую группировку
логически связанной структуры;
2.
наследование позволяет легко и многократно
использовать эти общие группы в других абстракциях.
Общая
характеристика объектов
•
Объект — это конкретное представление
абстракции. Объект обладает индивидуальностью, состоянием и поведением.
Структура и поведение подобных объектов определены в их общем классе. Термины
«экземпляр класса» и «объект» взаимозаменяемы.
•
Индивидуальность — это характеристика
объекта, которая отличает его от всех других объектов.
•
Состояние объекта характеризуется
перечнем всех свойств объекта и текущими значениями каждого из этих свойств
(рис. ).
Рис. Представление объекта с именем Стул
Объекты не существуют
изолированно друг от друга. Они подвергаются воздействию или сами воздействуют
на другие объекты.
Поведение характеризует
то, как объект воздействует на другие объекты (или подвергается воздействию) в
терминах изменений его состояния и передачи сообщений. Поведение объекта
является функцией как его состояния, так и выполняемых им операций (Купить,
Продать, Взвесить, Переместить, Покрасить). Говорят, что состояние объекта
представляет суммарный результат его поведения.
Операция обозначает
обслуживание, которое объект предлагает своим клиентам. Возможны пять видов
операций клиента над объектом:
•
модификатор (изменяет состояние объекта);
•
селектор (дает доступ к состоянию, но не изменяет
его);
•
итератор (доступ к содержанию объекта по частям,
в строго определенном порядке);
•
конструктор (создает объект и инициализирует его
состояние);
•
деструктор (разрушает объект и освобождает
занимаемую им память).
Виды отношений
между объектами
В поле зрения
разработчика ПО находятся не объекты-одиночки, а взаимодействующие объекты,
ведь именно взаимодействие объектов реализует поведение системы. У Г. Буча есть
отличная цитата из Галла: «Самолет — это набор элементов, каждый из которых по
своей природе стремится упасть на землю, но ценой совместных непрерывных усилий
преодолевает эту тенденцию» [22]. Отношения между парой объектов основываются
на взаимной информации о разрешенных операциях и ожидаемом поведении. Особо
интересны два вида отношений между объектами: связи и агрегация.
Связи
Связь — это физическое
или понятийное соединение между объектами. Объект сотрудничает с другими
объектами через соединяющие их связи. Связь обозначает соединение, с помощью
которого:
•
объект-клиент вызывает операции
объекта-поставщика;
•
один объект перемещает данные к другому объекту.
Можно сказать, что
связи являются рельсами между станциями-объектами, по которым ездят
«трамвайчики сообщений».
Связи между объектами
показаны на рис. 9.5 с помощью соединительных линий. Связи представляют
возможные пути для передачи сообщений. Сами сообщения показаны стрелками,
отмечающими их направления, и помечены именами вызываемых операций.
Как участник связи
объект может играть одну из трех ролей:
•
актер — объект, который может воздействовать на
другие объекты, но никогда не подвержен воздействию других объектов;
•
сервер — объект, который никогда не воздействует
на другие объекты, он только используется другими объектами;
•
агент — объект, который может как воздействовать
на другие объекты, так и использоваться ими. Агент создается для выполнения
работы от имени актера или другого агента.
Рис. Связи между объектами
Связи между объектами
показаны на рис. с помощью
соединительных линий. Связи представляют возможные пути для передачи сообщений.
Сами сообщения показаны стрелками, отмечающими их направления, и помечены
именами вызываемых операций.
Видимость объектов
Рассмотрим два
объекта, А и В, между которыми имеется связь. Для того чтобы объект А мог
послать сообщение в объект В, надо, чтобы В был виден для А.
Различают четыре формы
видимости между объектами.
1. Объект-поставщик
(сервер) глобален для клиента.
2. Объект-поставщик
(сервер) является параметром операции клиента.
3. Объект-поставщик
(сервер) является частью объекта-клиента.
4. Объект-поставщик
(сервер) является локально объявленным объектом в операции клиента.
На этапе анализа
вопросы видимости обычно опускают. На этапах проектирования и реализации
вопросы видимости по связям обязательно должны рассматриваться.
Агрегация
Связи обозначают
равноправные (клиент-серверные) отношения между объектами. Агрегация обозначает
отношения объектов в иерархии «целое/часть». Агрегация обеспечивает возможность
перемещения от целого (агрегата) к его частям (свойствам).
Агрегация может
обозначать, а может и не обозначать физическое включение части в целое. На рис.
9.7 приведен пример физического включения (композиции) частей (Двигателя,
Сидений, Колес) в агрегат Автомобиль. В этом случае говорят, что части включены
в агрегат по величине.
Рис. 9.7. Физическое
включение частей в агрегат
Рис. 9.8. Нефизическое
включение частей в агрегат
На рис. 9.8 приведен
пример нефизического включения частей (Студента, Преподавателя) в агрегат Вуз.
Очевидно, что Студент и Преподаватель являются элементами Вуза, но они не
входят в него физически. В этом случае говорят, что части включены в агрегат по
ссылке.
Итак, между объектами
существуют два вида отношений — связи и агрегация. Какое из них выбрать?
При выборе вида
отношения должны учитываться следующие факторы:
•
связи обеспечивают низкое сцепление между
объектами;
•
агрегация инкапсулирует части как секреты
целого.
Общая
характеристика классов
Класс —
описание множества объектов, которые разделяют одинаковые свойства, операции,
отношения и семантику (смысл). Любой объект — просто экземпляр класса.
Различают внутреннее
представление класса (реализацию) и внешнее представление класса (интерфейс).
Интерфейс объявляет
возможности (услуги) класса, но скрывает его структуру и поведение. Иными
словами, интерфейс демонстрирует внешнему миру абстракцию класса, его внешний
облик. Интерфейс в основном состоит из объявлений всех операций, применимых к
экземплярам класса. Он может также включать объявления типов, переменных,
констант и исключений, необходимых для полноты данной абстракции.
Рис. 9.9. Структуре
представления класса
Интерфейс может быть
разделен на 3 части:
1.
публичную (public), объявления которой доступны
всем клиентам;
2.
защищенную (protected), объявления которой
доступны только самому классу, его подклассам и друзьям;
3.
приватную (private), объявления которой
доступны только самому классу и его друзьям.
4.
Другом класса называют класс, который имеет
доступ ко всем частям этого класса (публичной, защищенной и приватной). Иными
словами, от друга у класса нет секретов.
5.
ПРИМЕЧАНИЕ
6.
Другом класса может быть и свободная
подпрограмма.
7.
Реализация класса описывает секреты поведения
класса. Она включает реализации всех операций, определенных в интерфейсе
класса.
Виды отношений
между классами
Классы, подобно
объектам, не существуют в изоляции. Напротив, с отдельной проблемной областью
связывают ключевые абстракции, отношения между которыми формируют структуру из
классов системы.
Всего существует
четыре основных вида отношений между классами:
1.
ассоциация (фиксирует структурные отношения —
связи между экземплярами классов);
2.
зависимость (отображает влияние одного класса на
другой класс);
3.
обобщение-специализация («is а»-отношение);
4.
целое-часть («part of»-отношение).
5.
Для покрытия основных отношений большинство
объектно-ориентированных языков программирования поддерживает следующие
отношения:
6.
1) ассоциация;
7.
2) наследование;
8.
3) агрегация;
9.
4) зависимость;
10.
5) конкретизация;
11.
6) метакласс;
12.
7) реализация.
Ассоциации классов
Ассоциации
обеспечивают взаимодействия объектов, принадлежащих разным классам. Они
являются клеем, соединяющим воедино все элементы программной системы. Благодаря
ассоциациям мы получаем работающую систему. Без ассоциаций система превращается
в набор изолированных классов-одиночек.
•
Ассоциация обозначает семантическое соединение
классов.
Рис. Ассоциация
Пример: в
системе обслуживания читателей имеются две ключевые абстракции — Книга и
Библиотека. Класс Книга играет роль элемента, хранимого в библиотеке. Класс
Библиотека играет роль хранилища для книг.
Отношение ассоциации
между классами изображено на рис.
Очевидно, что ассоциация предполагает двухсторонние отношения:
для данного экземпляра
Книги выделяется экземпляр Библиотеки, обеспечивающий ее хранение;
для данного экземпляра
Библиотеки выделяются все хранимые Книги.
Здесь показана
ассоциация один-ко-многим. Каждый экземпляр Книги имеет указатель на
экземпляр Библиотеки. Каждый экземпляр Библиотеки имеет набор указателей на
несколько экземпляров Книги.
Ассоциация обозначает
только семантическую связь. Она не указывает направление и точную реализацию
отношения. Ассоциация пригодна для анализа проблемы, когда нам требуется лишь
идентифицировать связи. С помощью создания ассоциаций мы приводим к пониманию
участников семантических связей, их ролей, мощности (количества элементов).
Ассоциация один-ко-многим,
введенная в примере, означает, что для каждого экземпляра класса Библиотека
есть 0 или более экземпляров класса Книга, а для каждого экземпляра класса
Книга есть один экземпляр Библиотеки. Эту множественность обозначает мощность
ассоциации.
Мощность ассоциации
бывает одного из трех типов:
•
один-к-одному;
•
один-ко-многим;
•
многие-ко-многим.
Рис. Ассоциации с различными типами мощности
Наследование
Наследование —
наиболее популярная разновидность отношения обобщение-специализация. Альтернативой
наследованию считается делегирование. При делегировании объекты делегируют свое
поведение родственным объектам. При этом классы становятся не нужны.
Наследование — это
отношение, при котором один класс разделяет структуру и поведение, определенные
в одном другом (простое наследование) или во многих других (множественное
наследование) классах.
Между п классами
наследование определяет иерархию «является» («is а»), при которой подкласс
наследует от одного или нескольких более общих суперклассов. Говорят, что
подкласс является специализацией его суперкласса (за счет дополнения или
переопределения существующей структуры или поведения).
Рис. 9.12. Иерархия
простого наследования
Здесь ПараметрыПолета
— базовый (корневой) суперкласс, подклассами которого являются Экипаж,
ПараметрыДвижения, Приборы, Кабина. В свою очередь, класс ПараметрыДвижения
является суперклассом для его подклассов Координаты, Скорость, Ориентация.
Полиморфизм
Полиморфизм —
возможность с помощью одного имени обозначать операции из различных классов (но
относящихся к общему суперклассу). Вызов обслуживания по полиморфному имени
приводит к исполнению одной из некоторого набора операций.
Источник