Способ установления отношений между объектами это

Урок №146. Типы связей между объектами

Обновл. 13 Сен 2021 |

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

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

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

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

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

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

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

Связи между объектами в программировании

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

Квадрат «является» геометрической фигурой.

Автомобиль «имеет» руль.

Программист «использует» клавиатуру.

Цветок «зависит от» растения.

Ученик является «членом» класса.

Наш мозг существует как «часть» нас самих.

Все эти типы отношений имеют свои аналоги в языке C++.

На следующих уроках мы рассмотрим нюансы типов отношений «имеет», «использует», «зависит от», «член чего-то» и «часть чего-то», и покажем, как они могут быть полезными в контексте классов в C++.

Затем мы перейдем к изучению отношений типа «является», рассматривая наследование и виртуальные функции в C++.

Поделиться в социальных сетях:

Источник

3.2. Отношения между объектами

3.2. Отношения между объектами

Типы отношений

Сами по себе объекты не представляют никакого интереса: только в процессе взаимодействия объектов реализуется система. По выражению Ингалса: «Вместо процессора, беззастенчиво перемалывающего структуры данных, мы получаем сообщество хорошо воспитанных объектов, которые вежливо просят друг друга об услугах» [13]. Самолет, по определению, «совокупность элементов, каждый из которых по своей природе стремится упасть на землю, но за счет совместных непрерывных усилий преодолевающих эту тенденцию» [14]. Он летит только благодаря согласованным усилиям своих компонентов.

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

Зайдевиц и Старк назвали эти два типа отношений отношениями старшинства и «родитель/потомок» соответственно [15].

Связи

Семантика. Мы заимствуем понятие связи у Румбаха, который определяет его как «физическое или концептуальное соединение между объектами» [16]. Объект сотрудничает с другими объектами через связи, соединяющие его с ними. Другими словами, связь — это специфическое сопоставление, через которое клиент запрашивает услугу у объекта-сервера или через которое один объект находит путь к другому.

На рис. 3-2 показано несколько разных связей. Они отмечены линиями и означают как бы пути прохождения сообщений. Сами сообщения показаны стрелками (соответственно их направлению) и помечены именем операции. На рисунке объект aController связан с двумя объектами класса DisplayItem (объекты a и b). В свою очередь, оба, вероятно, связаны с aView, но нам была интересна только одна из этих связей. Только вдоль связи один объект может послать сообщение другому.

Связь между объектами и передача сообщений обычно односторонняя (как на рисунке; хотя технически она может быть и взаимной). Как мы увидим в главе 5, подобное разделение прав и обязанностей типично для хорошо структурированных объектных систем [На самом деле организация объектов, показанная на рис. 3-2, встречается настолько часто, что ее можно считать типовым проектным решением. В Smalltalk аналогичный механизм известен как MVC, model/view/controller (модель/представление/контроллер). Как мы увидим в следующей главе, хорошо структурированные системы имеют много таких опознаваемых типовых решений]. Заметьте также, что хотя передаваемое сообщение инициализировано клиентом (в данном случае aController), данные передаются в обоих направлениях. Например, когда aController вызывает операцию move для пересылки данных объекту а, данные передаются от клиента серверу, но при выполнении операции isUnder над объектом b, результат передается от сервера клиенту.

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

? Актер [Actor — это деятель, исполнитель. А исполнитель ролей, это и есть актер. — Примеч. ред.]. Объект может воздействовать на другие объекты, но сам никогда не подвергается воздействию других объектов; в определенном смысле это соответствует понятию активный объект.

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

? Агент. Такой объект может выступать как в активной, так и в пассивной роли; как правило, объект-агент создается для выполнения операций в интересах какого-либо объекта-актера или агента.

На рис. 3-2 объект aController выступает как актер, объект a — как агент и объект aView — как сервер.

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

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

// Число прошедших минут typedef unsigned int Minute;

Теперь опишем сам класс TemperatureRamp, который по смыслу задает функцию времени от температуры:

class TemperatureRamp < public:

TemperatureRamp(); virtual

TemperatureRamp(); virtual void clear(); virtual void bind (Temperature, Minute); Temperature TemperatureAt (Minute);

protected: . >;

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

На самом деле в смысле поведения нам надо нечто большее, чем просто зависимость температуры от времени. Пусть, например, известно, что на 60-й минуте должна быть достигнута температура 250?F, а на 180-й — 150?F. Спрашивается, какой она должна быть на 120-й минуте? Это требует линейной интерполяции, так что требуемое от абстракции поведение усложняется.

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

class TemperatureController < public:

TemperatureController(); void process(const TemperatureRamp&); Minute schedule(const TemperatureRamp&) const;

private: . >;

Тип Location был определен в главе 2. Заметьте, что мы не ожидаем наследования от этого класса и поэтому не объявляем в нем никаких виртуальных функций.

Операция process обеспечивает основное поведение этой абстракции; ее назначение — передать график изменения температуры нагревателю, установленному в конкретном месте. Например, объявим:

TemperatureRamp growingRamp; TemperatureController rampController(7);

Теперь зададим пару точек и загрузим план в контроллер::

growingRamp.bind (250, 60); growingRamp.bind(150, 180); rampController.process(growingRamp);

В этом примере rampController — агент, ответственный за выполнение температурного плана, он использует объект growingRamp как сервер. Эта связь проявляется хотя бы в том, что rampController явно получает growingRamp в качестве параметра одной из своих операций.

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

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

В предыдущем примере объект rampController видит объект growingRamp, поскольку оба они объявлены в одной области видимости и потому, что growingRamp передается объекту rampController в качестве параметра. В принципе есть следующие четыре способа обеспечить видимость.

• Сервер глобален по отношению к клиенту.

• Сервер (или указатель на него) передан клиенту в качестве параметра операции.

• Сервер является частью клиента.

• Сервер локально порождается клиентом в ходе выполнения какой-либо операции.

Какой именно из этих способов выбрать — зависит от тактики проектирования.

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

• Последовательный — семантика пассивного объекта обеспечивается в присутствии только одного активного процесса.

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

• Синхронный — семантика пассивного объекта обеспечивается в присутствии многих потоков управления; взаимное исключение обеспечивает сервер.

Все объекты, описанные в этой главе, были последовательными. В главе 9 мы рассмотрим остальные варианты более подробно.

Агрегация

Семантика. В то время, как связи обозначают равноправные или «клиент-серверные» отношения между объектами, агрегация описывает отношения целого и части, приводящие к соответствующей иерархии объектов, причем, идя от целого (агрегата), мы можем придти к его частям (атрибутам). В этом смысле агрегация — специализированный частный случай ассоциации. На рис. 3-3 объект rampController имеет связь с объектом growingRamp и атрибут h класса Heater (нагреватель). В данном случае rampController — целое, a h — его часть. Другими словами, h — часть состояния rampController. Исходя из rampController, можно найти соответствующий нагреватель. Однако по h нельзя найти содержащий его объект (называемый также его контейнером), если только сведения о нем не являются случайно частью состояния h.

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

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

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

Пример. Добавим в спецификацию класса TemperatureController описание нагревателя:

Heater h;

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

TemperatureController::TemperatureController(Location 1) : h(1) <>

Читайте также

Операторы отношения

Операторы отношения Операторы отношения используются для сравнения значений нескольких переменных. Эти операторы, описанные в табл. П1.7, могут возвращать только логические значения true или false.Таблица П1.7. Операторы отношения Оператор Условие, при котором возвращается

5.2. Отношения между классами

5.2. Отношения между классами Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами. При этом совокупность типов таких отношений фиксирована в языке UML и предопределена семантикой этих типов

Различия между управляющими объектами (drivers) и ограничениями

Различия между управляющими объектами (drivers) и ограничениями Управляющие объекты и ограничения похожи тем, что они влияют на изменение свойств пути (речь идет о параметрах анимации — прим. пер.), но в тоже время они очень разные: ограничения действуют непосредственно на

R.5.9 Операции отношения

R.5.9 Операции отношения Операции отношения выполняются слева направо, но этот факт мало что дает, ибо выражение a‹b‹c означает (a‹b)‹c, а вовсе не (a‹b)&&(b‹c).выражение-отношения: сдвиговое-выражение выражение-отношения ‹ сдвиговое-выражение выражение-отношения ›

Отношения

Отношения Отношение — это способ формального определения того, как две таблицы связаны друг с другом. При определении отношения необходимо сообщить процессору баз данных, через какие два поля связываются две таблицы, участвующие в создании отношения. РИС. 1.12. Схема

3.4. Отношения между классами

3.4. Отношения между классами Типы отношений Рассмотрим сходства и различия между следующими классами: цветы, маргаритки, красные розы, желтые розы, лепестки и божьи коровки. Мы можем заметить следующее: • Маргаритка — цветок. • Роза — (другой) цветок. • Красная и желтая

Работа с MBV-объектами

Работа с MBV-объектами Наши первые приложения удаленного взаимодействия позволяли доступ клиентов к одному WKO-типу. Напомним, что WKO-типы (по определению) являются MBR-типами, поэтому доступ клиента к ним осуществляется через агента-посредника. В противоположность этому,

4.5.4. Функции для тестирования пространственных отношений между геометрическими объектами

4.5.4. Функции для тестирования пространственных отношений между геометрическими объектами Функции, описанные в этих разделах, берут две конфигурации как входные параметры и возвращают качественное или количественное отношение между

Операции с объектами

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

7.6 Операции Отношения

7.6 Операции Отношения Операции отношения (сравнения) группируют слева направо, но этот факт не очень-то полезен: a « b « c не означает то, чем кажется.выражение_отношения: выражение « выражение выражение » выражение выражение «= выражение выражение »= выражениеОперации «

Врата чувств: о чём свидетельствуют отношения между нашим архаичным обонянием и эволюционно продвинутым зрением Дмитрий Шабанов

Врата чувств: о чём свидетельствуют отношения между нашим архаичным обонянием и эволюционно продвинутым зрением Дмитрий Шабанов Опубликовано 06 мая 2013 В этой колонке я затрону факты и догадки, которые кажутся мне по-настоящему интригующими. Жаль

12.7. Многотабличные базы данных. Отношения между таблицами

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

Что происходит с объектами

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

6.3.6. Управляем объектами

6.3.6. Управляем объектами Для выполнения заданий нам понадобится материал разд. 5.3.3.Вспомним, какие действия будут происходить на слайде.? Звук начинает проигрываться с самого начала С самого же начала появляется текст с фоном.? Затем при чтении слова «Ивашка» появляется

Источник