ВВЕДЕНИЕ
На протяжении всех лет существования практика программирования требовала совершенствования технологических приемов и создания на их основе таких средств программирования, которые упростили бы процесс разработки программ, позволяя создавать все более сложные программные системы.
Первые программы были организованы очень просто. Они состояли из собственно программы на машинном языке и обрабатываемых данных. Сложность программ ограничивалась способностью программиста одновременно мысленно отслеживать последовательность выполняемых операций и местонахождение большого количества данных.
Создание сначала ассемблеров, а затем и языков высокого уровня сделало программу более обозримой за счет снижения уровня детализации и естественно позволило увеличить ее сложность.
Появление в языках средств, позволяющих оперировать подпрограммами, существенно снизило трудоемкость разработки программ. Подпрограммы можно было сохранять и использовать в других программах. В результате были накоплены огромные библиотеки расчетных и служебных подпрограмм, которые по мере надобности вызывались из разрабатываемой программы. Типичная программа того времени состояла из основной программы, области глобальных данных и набора подпрограмм, выполняющих обработку всех данных или их части.
Слабым местом такой архитектуры было то, что при увеличении количества подпрограмм возрастала вероятность искажения части глобальных данных какой-либо подпрограммой. Например, обычно подпрограмма поиска корней уравнения на заданном интервале по методу деления отрезка пополам меняет величину интервала. Если при выходе из подпрограммы не предусмотреть восстановления первоначального интервала, то в глобальной области окажется неверное значение интервала, полученное при последнем делении отрезка в ходе работы подпрограммы.
Необходимость исключения таких ошибок привела к идее использования в подпрограммах локальных данных.
И вновь сложность разрабатываемого программного обеспечения стала ограничиваться возможностью программиста отслеживать процессы обработки данных уже на новом уровне. К этому добавились проблемы согласования интерфейса при ведении разработки несколькими программистами. В результате встал вопрос создания технологии разработки сложных программных продуктов, снижающей вероятность появления ошибок.
Усилиями многих авторов такая технология была создана и получила название «структурное программирование».
Структурное программирование представляет собой совокупность рекомендуемых технологических приемов, охватывающих выполнение всех этапов разработки программного обеспечения.
Были сформулированы основные принципы проектирования и реализации программного обеспечения:
- принцип нисходящей разработки, рекомендующий на всех этапах вначале определять наиболее общие моменты, а затем поэтапно выполнять детализацию (что позволяет последовательно концентрировать внимание на небольших фрагментах разработки);
- собственно структурное программирование, рекомендующее определенные структуры алгоритмов и стиль программирования (чем нагляднее текст программы, тем меньше вероятность ошибки);
- принцип сквозного структурного контроля, предполагающий проведение содержательного контроля всех этапов разработки (чем раньше обнаружена ошибка, тем проще ее исправить).
Сформулированная таким образом методика структурной декомпозиции закрепила сложившийся в то время алгоритмический подход к программированию, при котором основное внимание концентрируется на определении последовательности действий.
Дальнейший рост сложности и размеров разрабатываемого программного обеспечения потребовал развития способов представления структурированных данных и, соответственно, в языках появилась возможность определения пользовательских типов данных. Одновременно усиливается стремление разграничить доступ к глобальным данным программы для уменьшения количества ошибок. Результатом было появление и развитие технологии модульного программирования.
Модульное программирование предполагает выделение групп подпрограмм, использующих одни и те же глобальные данные, в отдельно компилируемые модули (библиотеки подпрограмм), например, модуль графических ресурсов, модуль подпрограмм вывода на принтер и т. п. Связи между модулями осуществляются через специальный интерфейс, в то время как доступ к реализации модуля (телам подпрограмм и некоторым «внутренним» переменным) запрещен.
Использование модульного программирования существенно упростило ведение разработки программ несколькими программистами, каждый из которых разрабатывает свои модули.
Практика программирования показала, что структурный подход в сочетании с модульным программированием позволил получить достаточно надежные программы, размер которых не превышает 100000 операторов. Узким местом модульного программирования явилось то, что ошибка в интерфейсе при вызове подпрограммы выявляется только при выполнении программы (из-за раздельной компиляции модулей обнаружить эти ошибки раньше невозможно). При увеличении размера программы свыше 100 000 операторов обычно возрастает сложность межмодульных интерфейсов, и предусмотреть взаимовлияние отдельных частей программы становится практически невозможно.
Стремление уменьшить количество связей между отдельными частями программы привело к появлению объектно-ориентированного программирования.
ООП — это технология создания сложного программного обеспечения, которая основана на представлении программы в виде совокупности программных объектов, каждый из которых является экземпляром определенного типа (класса), а классы образуют иерархию с наследованием свойств.
Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений.
Объектный подход предлагает новые технологические средства разработки такие, как наследование, полиморфизм, композиция, наполнение, позволяющие конструировать сложные классы из сравнительно простых. В результате существенно увеличивается показатель повторного использования кодов, появляется возможность создания библиотек классов для различных применений, и разработчикам предоставляются дополнительные возможности создания систем повышенной сложности.
Объектно-ориентированное проектирование является этапом, на котором прорабатываются основные вопросы строения будущей программной системы. Правильное проведение проектирования позволяет избежать множества затрат. Освоение умения проектировать необходимо для последующей работы любого создателя информационных систем.
Представленные в методических указаниях лабораторные работы ознакомят студентов со спецификой объектного мышления и научат проектировать сложные системы.
Декомпозиция
Под предметной областью обычно понимают часть реального мира, которую описывают в программе.
При создании сложных программ или программных комплексов выполняется декомпозиция предметной области. При декомпозиции предметная область представляется как система.
Декомпозиция — это выявление структуры и организации системы. Система при декомпозиции представляется как нечто целостное, и вместе с тем составленная из простых компонентов.
Различают алгоритмическую (функциональную) и объектно-ориентированную декомпозиции.
Алгоритмическая декомпозиция основывается на разбиении системы на действия — алгоритмы. Система делится на подсистемы, которые делятся на более мелкие подсистемы и т.д. Конечными элементами такого деления являются процедуры и функции. Иллюстрацией такой декомпозиции служит функциональная схема (рис.1).
Объектно-ориентированная декомпозиция обеспечивает разбиение на взаимодействующие объекты некоторой системы, имитирующей процессы, происходящие в предметной области поставленной задачи.
В такой системе каждый объект, получив в процессе решения задачи некоторое входное воздействие (сообщение), выполняет заранее определенные действия. Например, он может изменить собственное состояние, выполнить некоторые вычисления, нарисовать окно или график и в свою очередь воздействовать на другие элементы. Передавая сообщения от элемента к элементу, система выполняет необходимые действия.
При объектно-ориентированном проектировании определяются абстракции и механизмы, обеспечивающие правильное поведение модели. Шклаер и Меллор выделили следующих кандидатов на роль объектов:
Материальные предметы: датчики, автомобили, автоматы.
Роли: учитель, контролер, отец, подчиненный.
События: требование, запрос, прерывание.
Взаимодействие: собрание, пресечение, заем.
Декомпозиция вообще и в частности объектная декомпозиция — работа интеллектуальная и лучший способ ее ведения — последовательный итеративный процесс. Сначала из возможных кандидатов строится приближенная модель системы. Затем по мере получения новых знаний модель уточняется, вводятся новые объекты, исключаются ненужные, объекты объединяются или разбиваются.
Например, для задачи создания просмотрщика графических файлов, обладающего следующими свойствами:
- анализ типа файла;
- получение информации об изображении;
- масштабирование изображения;
- поворот изображения на произвольное количество градусов;
- слайдшоу.
Можно выполнить алгоритмическую декомпозицию, показанную на рис.1.
Рис.1. Функциональная схема просмотрщика графических файлов
Объектная декомпозиция для той же задачи может выглядеть следующим образом (рис.2).
Каждый из объектов модели играет роль согласно выполняемым действиям. Объект «Менеджер» управляет последовательностью действий, выполняемых при просмотре. Объект «Диалог выбора файла» взаимодействует с объектом «Файл», производит поиск необходимого файла и загружает его. Объект «Транслятор» проводит анализ типа файла и преобразует загруженный файл в изображение в форме для отображения. Это изображение представляется в виде объекта «Изображение». Объект «Конфигуратор» загружает и предоставляет режим и параметры отображения. И, наконец, объект «Область отображения» выводит изображение на экран в соответствии с заданным режимом и параметрами отображения.
Отношения между классами
Рассмотрим сходства и различия классов для следующих объектов: цветы, маргаритки, красные розы, желтые розы и лепестки. Сделаем следующие выводы:
- Маргаритка — вид цветка.
- Роза — (другой) вид цветка.
-
- Красная и желтая розы — разновидность розы.
- Лепесток является частью обоих видов цветов.
Из этого простого примера следует, что классы, как и объекты, не существуют изолированно. Наоборот, структура классов для конкретной области формируется на основе ключевых абстракций этой области и их связей. Отношение между двумя классами следует рассмотреть по двум причинам. Во-первых, отношения классов могут указывать на какой-либо вид общности. Например, маргаритки и розы являются разновидностями цветов, имеют яркую окраску лепестков, сильный аромат и т.д. Во-вторых, отношения классов могут влиять на семантику связи между ними. Можно отметить, что между красными и желтыми розами больше сходства, чем между розами и маргаритками, а между маргаритками и розами больше, чеммежду лепестками и цветами.
Известны три основных типа отношений между классами. Первый тип называется отношением «разновидность» и отражает степень общности. Например, фраза «роза является разновидностью цветов» означает, что роза является более специализированным подклассом класса цветов. Второй тип отражает агрегатирование объектов и называется отношением «составная часть». Так, например, лепесток — не разновидность цветка, а его составная часть. Третий тип обозначает отношение ассоциативности, т.е. смысловую связь между классами, которые не связаны никакими другими типами отношений. Примером могут служить два достаточно независимых класса: класс роз и класс маргариток, которые соответствуют объектам, пригодным для декоративного оформления обеденного стола.
Для покрытия основных отношений большинство объектно-ориентированных языков программирования поддерживают следующие отношения:
- ассоциация;
- наследование;
- агрегация;
- зависимость;
- конкретизация.
Ассоциации обеспечивают взаимодействия объектов, принадлежащих разным классам. Они являются клеем, соединяющим воедино все элементы программной системы. Благодаря ассоциациям мы получаем работающую систему. Без ассоциаций система превращается в набор изолированных классов-одиночек.
Наследование — наиболее популярная разновидность отношения обобщение-специализация. Альтернативой наследованию считается делегирование. При делегировании объекты делегируют свое поведение родственным объектам. При этом классы становятся не нужны.
Агрегация обеспечивает отношения целое-часть, объявляемые для экземпляров классов.
Зависимость часто представляется в виде частной формы — использования. Зависимость фиксирует отношение между клиентом, запрашивающим услугу, и сервером, предоставляющим эту услугу.
Конкретизация выражает другую разновидность отношения обобщение-специализация.
Ассоциации классов
Ассоциация обозначает семантическое соединение классов.
Пример: в системе обслуживания читателей имеются две ключевые абстракции — Книга и Библиотека. Класс Книга играет роль элемента, хранимого в библиотеке. Класс Библиотека играет роль хранилища для книг.
Рис. 5. Ассоциация
Отношение ассоциации между классами изображено на рис.5. Очевидно, что ассоциация предполагает двухсторонние отношения:
- для данного экземпляра Книги выделяется экземпляр Библиотеки, обеспечивающий ее хранение;
- для данного экземпляра Библиотеки выделяются все хранимые Книги.
Здесь показана ассоциация один-ко-многим. Каждый экземпляр Книги имеет указатель на экземпляр Библиотеки. Каждый экземпляр Библиотеки имеет набор указателей на несколько экземпляров Книги.
Ассоциация обозначает только семантическую связь. Она не указывает направление и точную реализацию отношения. Ассоциация пригодна для анализа проблемы, когда нам требуется лишь идентифицировать связи. С помощью создания ассоциаций мы приходим к пониманию участников семантических связей, их ролей, мощности, (количества элементов).
Ассоциация один-ко-многим, введенная в примере, означает, что для каждого экземпляра класса Библиотека есть 0 или более экземпляров класса Книга, а для каждого экземпляра класса Книга есть один экземпляр Библиотеки. Эту множественность обозначает мощность ассоциации. Мощность ассоциации бывает одного из трех типов:
- один-к-одному;
- один-ко-многим;
- многие-ко-многим.
Примеры ассоциаций с различными типами мощности приведены на рис.6, они имеют следующий смысл:
- у европейской жены один муж, а у европейского мужа одна жена;
- у восточной жены один муж, а у восточного мужа сколько угодно жен;
- у заказа один клиент, а у клиента сколько угодно заказов;
- человек может посещать сколько угодно зданий, а в здании может находиться сколько угодно людей.
Рис. 6. Ассоциации с различными типами мощности
Наследование
Наследование — это отношение, при котором класс разделяет структуру и поведение, определенные в одном другом (простое наследование) или во многих других (множественное наследование) классах.
Между п классами наследование определяет иерархию «является» («is а»), при которой подкласс наследует от одного или нескольких более общих суперклассов. Говорят, что подкласс является специализацией его суперкласса (за счет дополнения или переопределения существующей структуры или поведения).
Пример: дана система для записи параметров полета в «черный ящик», установленный в самолете. Организуем систему в виде иерархии классов, построенной на базе наследования.
Иерархическая структура классов системы для записи параметров полета, находящихся в отношении наследования, показана на рис. 7.
Рис. 7. Иерархия простого наследования
Здесь ПараметрыПолета — базовый (корневой) суперкласс, подклассами которого являются Экипаж, ПараметрыДвижения, Приборы, Кабина. В свою очередь, класс ПараметрыДвижения является суперклассом для его подклассов Координаты, Скорость, Ориентация.
Полиморфизм
Полиморфизм — возможность с помощью одного имени обозначать операции из различных классов (но относящихся к общему суперклассу). Вызов обслуживания по полиморфному имени приводит к исполнению одной из некоторого набора операций.
Рассмотрим различные реализации процедуры Записывать. Для класса ПараметрыПолета реализация имеет вид
procedure Записывать(c:ПараметрыПолета).
В классе Кабина предусмотрена другая реализация процедуры:
procedure Записывать(c:Кабина).
Предположим, что мы имеем по экземпляру каждого из этих двух классов:
Предположим также, что имеется свободная процедура:
procedure СохранятьНовДанные (d:ПараметрыПолета);
begin
Записывать(d);
End.
Что случится при выполнении следующих операторов?
var
Вполете: ПараметрыПолета;
Вкабине:Кабина;
begin
СохранятьНовДанные (Вполете);
СохранятьНовДанные (Вкабине);
end.
Каждый из операторов вызывает операцию Записывать нужного класса. В первом случае диспетчеризация приведет к операции Записывать из класса ПараметрыПолета. Во втором случае будет выполняться операция из класса Кабина. Как видим, в свободной процедуре переменная d может обозначать объекты разных классов, значит, здесь записан вызов полиморфной операции.
Агрегация
Отношения агрегации между классами аналогичны отношениям агрегации между объектами.
Для класса Вагон можно поставить в соответствие классы Тележка, Кузов, Рама. Класс Вагон является агрегатом, а экземпляр класса Тележка — это одна из его частей. Агрегация здесь определена как включение по величине. Это — пример физического включения, означающий, что объект тележка не существует независимо от включающего его экземпляра Вагон. Время жизни этих двух объектов неразрывно связано.
Графическая иллюстрация отношения агрегации по величине (композиции) представлена на рис. 8.
Рис. 8. Отношение агрегации по величине (композиция)
Еще два примера агрегации по ссылке и по величине (композиции) приведены на рис. 9. Здесь показаны класс-агрегат Дом и класс-агрегат Окно, причем указаны роли и множественность частей агрегата (соответствующие пометки имеют линии отношений).
Как показано на рис. 10, возможны и другие формы представления агрегации по величине — композиции. Композицию можно отобразить графическим вложением символов частей в символ агрегата (левая часть рис. 10). Вложенные части демонстрируют свою множественность (мощность, кратность) в правом верхнем углу своего символа. Если метка множественности опущена, то по умолчанию считают, что ее значение «много».
Рис. 9. Агрегация классов
Рис. 10. Формы представления композиции
Зависимость
Зависимость — это отношение, которое показывает, что изменение в одном классе (независимом) может влиять на другой класс (зависимый), который использует его. Графически зависимость изображается как пунктирная стрелка, направленная на класс, от которого зависят. С помощью зависимости уточняют, какая абстракция является клиентом, а какая — поставщиком определенной услуги. Пунктирная стрелка зависимости направлена от клиента к поставщику.
Наиболее часто зависимости показывают, что один класс использует другой класс как аргумент в сигнатуре своей операции.
Конкретизация
Г. Буч определяет конкретизацию как процесс наполнения шаблона (родового или параметризованного класса). Целью является получение класса, от которого возможно создание экземпляров.
Родовой класс служит заготовкой, шаблоном, параметры которого могут наполняться (настраиваться) другими классами, типами, объектами, операциями. Он может быть родоначальником большого количества обычных (конкретных) классов. Возможности настройки родового класса представляются списком формальных родовых параметров. Эти параметры в процессе настройки должны заменяться фактическими родовыми параметрами. Процесс настройки родового класса называют конкретизацией.
Для Класс Очередь произведем настройку, то есть объявим два конкретизированных класса — ОчередьЦелыхЭлементов и ОчередьЛилипутов.
В первом случае мы настраивали класс на конкретный тип Integer (фактический родовой параметр), во втором случае — на конкретный тип Лилипут.
Классы ОчередьЦелыхЭлементов и ОчередьЛилипутов можно использовать как обычные классы. Они содержат все средства родового класса, но только эти средства настроены на использование конкретного типа, заданного при конкретизации.
Графическая иллюстрация отношений конкретизации приведена на рис. 11. Отметим, что отношение конкретизации отображается с помощью подписанной стрелки отношения зависимости. Это логично, поскольку конкретизированный класс зависит от родового класса (класса-шаблона).
Рис. 11. Отношения конкретизации родового класса
 |
Отношения между классами и объектами связаны с конкретными действиями. Если мы хотим, чтобы объект X послал объекту Y сообщение М, то прямо или косвенно класс X должен быть доступен («видим») для класса Y, иначе невозможно определить в классе X операцию М. Объект X также должен быть «видим» для Y, иначе Y не будет знать о существовании X. Под доступностью и видимостью понимается способность одной абстракции обращаться к внешним ресурсам другой абстракции. Таким образом, взаимозависимость является мерой видимости.
Одним из полезных правил является закон Деметера, который установил, что «методы любого класса не должны зависеть от структуры других классов, за исключением собственной структуры (верхнего уровня). В каждом методе посылаются сообщения только объектам из предельно ограниченного множества классов». Следование этому закону позволяет создавать близко связанные классы, реализация которых защищена от доступа. Такие классы достаточно автономны и для понимания их логики нет необходимости знать строение других классов. При анализе структуры классов для системы в целом можно обнаружить, что иерархия наследования либо широкая и мелкая, либо узкая и глубокая, либо сбалансированная.
В первом случае структура классов выглядит как лес из свободно стоящих классов, которые могут свободно смешиваться и вступать во взаимоотношения. Во втором случае структура классов напоминает одно дерево из ветвей-классов, имеющих общего предка. Каждый из вариантов имеет свои достоинства и недостатки. Между отдельными классами существует более тесная взаимозависимость, но совсем не используется общность структуры. В случае дерева классов эта общность используется максимально, поэтому каждый из классов имеет меньший размер.
Однако для понимания сущности таких классов нужно знать все особенности наследованных или использованных свойств других классов. Иногда требуется выбирать между отношениями наследования и использования. Например, следует ли в классе «автомобиль» использовать или наследовать классы «двигатель» и «колесо»? В данном случае более целесообразны отношения использования. По мнению Мейера, между классами А и В «отношения наследования более пригодны тогда, когда любой объект класса В может рассматриваться одновременно как объект А». Если же объект является больше, чем сумма отдельных частей, то более целесообразны отношения использования.
Отношения между объектами определяют в основном и механизмы их взаимодействия. Вопрос состоит только в направлении реализации определенных действий. Например, на ткацкой фабрике материалы (партии) поступают на участки для обработки. На каждом участке можно заменить управляющего. Является ли поступление материала на участок операцией над помещением, над материалом или тем и другим сразу? Если это операции над помещением, то помещение должно быть «видимо» для партии материала. Если это операция над материалом, то материал должен быть «видим» для помещения, так как партия материала должна различать помещения участков. В последнем варианте (операция над помещением и материалом) нужно обеспечить взаимную «видимость».
Теперь следует определить отношение между управляющим участком и помещением (но не материалом и управляющим); либо управляющий должен знать о помещении, либо помещение об управляющем. Иногда в процессе проектирования полезно определить в явном виде «видимость» объектов. Существуют три основных способа реализации видимости объекта X объекту Y:
1. Размещение в одной зоне видимости. Y находится в зоне видимости X. Поэтому X может прямо именовать Y.
2. Использование. Y передается в качестве параметра какой-либо операции над X.
3. Использование поля. Y является полем объекта X.
Эти способы являются вариациями идеи общей зоны «видимости». Y может быть полем X и при этом находится в зоне видимости других объектов. Общая зона видимости приводит к общности структуры, т.е. общая часть структуры доступна по нескольким направлениям. Такие отношения не всегда желательны, поэтому целесообразно пользоваться их явным указанием в процессе проектирования.
В лабораторной работе №1 были выделены абстракции. Определим отношения между ними. Для этого будем анализировать, в каких отношениях может находиться каждый из классов со всеми остальными классами.
Класс объектов «Файл» взаимодействует с классом объектов «Диалог выбора файла» и классом объектов «Транслятор». Эти взаимодействия соответствуют отношению зависимость. Следовательно, в классах объектов «Диалог выбора файла» и «Транслятор» должны присутствовать операции в качестве параметров использующие класс объектов «Файл». Видимость реализуется посредством использования.
Класс объектов «Изображение» взаимодействует с классом объектов «Область отображения» и классом объектов «Транслятор». Эти взаимодействия соответствуют отношению зависимость. Следовательно, в классах объектов «Область отображения» и «Транслятор» должны присутствовать операции в качестве параметров использующие класс объектов «Изображение». Видимость реализуется посредством использования.
Между классом объектов «Менеджер» и классами объектов «Диалог выбора файла», «Транслятор», «Область отображения» и «Конфигуратор» взаимодействия соответствуют отношению ассоциация. Видимость реализуется посредством размещения в одной зоне видимости.
Объекты и классы. Абстрагирование и обобщение
Объект
При объектной декомпозиции часть реального мира описывается в виде взаимодействующих объектов. Термин «объект» в программном обеспечении впервые введен в языке Simula и означал какой-либо аспект моделируемой реальности. Наиболее обще объект может быть определен как нечто, имеющее четко очерченные границы. Существуют такие объекты, для которых определены явные границы, но сами объекты представляют собой неосязаемые события или процессы. Например, процесс перевозок на железной дороге: его границы явно определены взаимодействием компонентов. Объекты могут быть осязаемыми, но иметь размытые физические границы. Например, реки, туман или толпы людей. Подобно тому, как взявший в руки молоток начинает видеть во всем окружающем только объекты для забивания, проектировщик с объектно-ориентированным мышлением начинает воспринимать весь мир в виде объектов. Разумеется, такой взгляд несколько упрощен, так как существуют понятия, явно не являющиеся объектами. К их числу относятся атрибуты такие, как время, красота, цвет, эмоции (например, любовь или гнев). Все перечисленное является свойствами, которые присущи объектам. Можно, например, утверждать, что некоторый человек (объект) любит свою жену (другой объект), или определенный кот (еще один объект) имеет серую шерсть.
На основе имеющегося опыта можно дать следующее определение:
Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс; термины «экземпляр класса» и «объект» — взаимозаменяемы.
Состояние
Для состояния объекта дадим следующее определение:
Состояние объекта характеризуется перечнем всех возможных (обычно статических) свойств данного объекта и текущими значениями (обычно динамическими) каждого из этих свойств.
Так у файла имеется свойство длина. Этому свойству соответствует динамическое значение, характеризующее количество байт в файле. В некоторых случаях значения свойств объекта могут быть статическими (например, заводской или инвентарный номер), поэтому в данном определении использован термин «обычно динамические».
К числу свойств объекта относятся присущие ему или приобретаемые характеристики, черты, качества или способности, делающие данный объект самим собой. Например, для подъемника характерным является то, что он сконструирован для подъема и спуска, но не для горизонтального перемещения. Перечень свойств объекта является, как правило, статическим, поскольку эти свойства составляют неизменяемую основу природы объекта.
Все свойства объекта характеризуются значениями их параметров. Эти значения могут быть простыми количественными характеристиками, а могут означать другой объект.
Тот факт, что всякий объект характеризуется состоянием означает, что он занимает определенное пространство (физически или в памяти компьютера).
Поведение
Объекты не существуют изолированно, а подвергаются воздействию или сами воздействуют на другие объекты.
Поведение характеризует то, как объект воздействует или подвергается воздействию других объектов с точки зрения изменения состояния этих объектов и передачи сообщений.
Другими словами, поведение объекта полностью определяется его действиями.
Операцией называется определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию. Например, объект файл-менеджер может активизировать операцию ChangeAttr для того, чтобы изменить атрибуты файла. Существует также операция: FileSize, которая позволяет определить размер файла, но не может изменить значение этого размера. Применительно к таким языкам программирования, как Smalltalk, принято говорить о передаче сообщений между объектами. В основном понятие «сообщение» совпадает с понятием «операции над объектами», но механизм их действий различен.
Как правило, в объектных и объектно-ориентированных языках операции, выполняемые над данным объектом, называются методами (методической частью объекта) и входят составной частью в определение класса.
Из практики известно пять основных видов операций над объектами:
- Модификатор. Операция, которая изменяет состояние объекта путем записи или доступа
- Селектор. Операция, дающая доступ для определения состояния объекта без его изменения (операция чтения)
- Итератор. Операция доступа к содержанию объекта по частям (в определенной последовательности).
- Конструктор. Операция создания и (или) инициализация объекта
- Деструктор. Операция разрушения объекта и (или) освобождение занимаемой им памяти.
Совокупность всех методов и общедоступных процедур, относящихся к конкретному объекту, образует протокол этого объекта. Протокол объекта, таким образом, определяет оболочку поведения объекта, охватывающую его внутреннее статическое и внешнее динамическое проявления.
Индивидуальность
Индивидуальность — это такие свойства объекта, которые отличают его от всех других объектов.
В большинстве языков программирования и баз данных для различения временных объектов, их взаимной адресации и идентификации используются имена переменных. Источником множества ошибок в объектно-ориентированном программировании является невозможность отличить имя объекта от самого объекта. Это связано с тем, что объекты всегда распределяются динамически и, следовательно, для них существуют: сам объект и ссылка (указатель) на объект, посредством которой производится доступ к объекту (рис.3).
Индивидуальность связана с вопросами присвоения и тождественности, а также временем существования объектов.
Для того, чтобы при присвоении объект был продублирован, необходимо либо переопределить операцию присвоения, либо создать специальную операцию, выполняющую дублирование. В противном случае будет производиться присвоение ссылок, что приведет к потери памяти и структурной неопределенности — ссылки на один и тот же объект (рис.4).
Тождественность представляется достаточно простой концепцией, но может обозначать одну из двух вещей. Во-первых, тождественность можно понимать как использование двух имен для обозначения одного и того же объекта. Во-вторых, тождественность может обозначать наличие одинакового состояния у двух разных объектов.
Началом времени существования любого объекта является момент его создания (отведение участка памяти), а окончанием — момент изъятия отведенного участка памяти. Объект продолжает существовать до тех пор, пока он занимает место в памяти, даже если будет потеряна ссылка на этот объект.