Информатика в техническом университете / Информатика в техническом университете. Объектно ориентированное программирование

I. Теоретические основы ООП

Активизировать

^<г

Рис. 1.10. Диаграмма объектов графического редактора

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

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

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

Пример 1.5. Объектная декомпозиция (программа «Записная книжка»). Попробуем вьшолнить объектную декомпозицию для программы «Записная книжка», на которой ранее демонстрировалась специфика процедурной декомпозиции (см. пример 1.1).

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

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

Добавим к системе еще несколько видимых объектов - сообщений пользователю, которые будут появляться на экране при обнаружении несоответствий в процессе работы, например, «Записная книжка не найдена» -

30

1.3. Объектная декомпозиция

Рис. 1.11. Диаграмма состояний интерфейса пользователя (первый вариант)

активизируется Открытием книжки или «Нет информации об абоненте» - активизируется Поиском записей (рис. 1.12).

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

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

Рис. 1.12. Полная диаграмма состояний интерфейса пользователя

31

1. Теоретические основы ООП

Объект Меню будет отвечать за выбор пунктов меню и вызов формы Открытие, формы Ввода и формы Поиска.

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

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

Форма Поиск должна вводить данные для поиска (фамилию или имя, или и то и другое сразу) и запрашивать поиск телефона по введенным данным.

Все операции с файлом будет вьшолнять объект Файл. Окончательный вариант объектной декомпозиции проектируемой

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

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

1. Для сложных систем объектная декомпозиция должна вьщолняться поэтапно: на первом этапе - объектная декомпозиция всей системы, на последующих - декомпозиция объектов как подсистем.

2. При декомпозиции системы в целом в качестве объектов могут вьщеляться элементы двух типов:

элементы интерфейса пользователя (окна меню, окна сообщений, окна форм ввода-вьгоода и т.д.);

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

При этом для каждого объекта должно определяться множество полу­ чаемых и передаваемых сообщений и основш>1е характеристики.

Рис. 1.13. Диаграмма объектов системы «Записная книжка»

32

1.4. Объекты и сообщения

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

1.4.Объекты и сообщения

Впредыдущем разделе было показано, что под объектом применительно

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

Каждый объект, получая сообщения, должен определенным образом «реагировать» на них, выполняя заранее определенные для каждого типа сообщения действия. Например, если объект Форма Открытие из примера 1.5 будет активизирован, то он должен запросить у пользователя имя файла, проверить наличие такого файла и затем либо открыть его, послав соответствующее сообщение объекту Файл, либо активизировать объект Сообщение «Записная книжка не найдена».

Реакция объекта на сообщите может зависеть от его состояния: так объект Файл, получив сообщение «Добавить запись», прежде чем добавлять запись, должен проверить, открыт ли соответствующий файл, и при закрытом файле должен вьщать пользователю отказ на вьшолнение операции добавления.

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

машин, тем занята колонка или нет, и в занятом состоянии - временем ее освобождения.

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

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

применением теории конечных автоматов.

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

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

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

33

1. Теоретические основы ООП

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

селекции.

Обращение к объекту для изменения его состояния по всем или отдельным составляющим инициирует выполнение операции модификации. Отправитель сообщения-^сол*анды, реакцией на которую должна быть модификация объекта, может ожидать завершения операции, а может продолжить выполнение своей программы. Второй вариант обработки называется асинхронным, и его реализация требует использования (или моделирования) параллельной обработки.

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

Полный список возможных операций над объектами выглядит следующим образом (рис. 1.14):

создание объекта; уничтожение объекта;

модификация - изменение состояния объекта; селекция - доступ для определения состояния;

итерация - доступ к содержимому объекта по частям в определенной последовательности (используется при наличии в объекте некоторых однотипных компонент).

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

Например, «Активизировать» для интерфейсного элемента, в зависимости от типа реализации (статической или динамической) может означать, либо создание объекта - при динамической реализации либо его

34

Сообщение

Объект 3 Пассивный объект

Рис. 1.15. Типы отношений между объектами

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

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

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

1.5. Классы

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

Классы. Для представления абстракций объектов используется специальный определяемьщ программистом тип данных - класс.

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

методов.

Реализация объединения данных с определенными видами их обработки делает классы пригодными для описания состояния и поведения моделей реальных объектов. Совокупность полей определяется множеством аспектов состояния объекта с точки зрения решаемой задачи, а совокупность методов - множеством аспектов поведения объекта (рис. 1.16).

В программах используются переменные типа класса. Такие переменные принято называть объектами.

35

Рис. 1.16. Соответствие объекта-абстракции классу и объектам-переменным

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

Проектируемый класс должен содержать поля для сохранения параметров окна: XI, Y1, Х2, Y2 - координаты верхнего левого и нижнего правого углов и Color - цвет.

рисования объекта. Поля объекта можно инициализировать при создании переменнойобъекта, передав ему сообщение иници­ ализации, включающее значения полей. Следовательно, класс должен содержать метод инициализации.

Окончательно получаем класс, имеющий следующую структуру:

Класс Окно:

поля X1,Y1,X2,Y2, Color

метод Инициализировать(аХ 1 ,aY 1 ,аХ2,аУ2,аСо1ог) метод Изобразить

Конец описания.

Создавая объекты типа Окно, инициализируя их в соответствии с условием и посылая им сообщение «Нарисовать окно», получим разные окна на экране, причем параметры этих окон будут храниться в объектах.

36

7.5. Классы

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

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

<имя объекта>.<имя поля>

или

<имя объекта>.<имя метода>.

Все методы объекта обязательно имеют доступ ко всем полям своего объекта. В рассматриваемых далее язьпсах программирования это достигается через неявную передачу в метод специального параметра - адреса области данных конкретного объекта (Self- в Паскале иtihis- в C++). Таким образом, уменьшается количество параметров, явно передаваемых в метод.

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

Класс <имя класса>

интерфейс

<объявление полей и методов класса,

ккоторым возможно обращение извне>

реализация

<объявление полей и методов класса,

ккоторым невозможно обращение извне>

Конец описания.

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

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

37

1. Теоретические основы ООП

Класс Интерфейс Реализация

^С ПоляМетоды'Ш^МетодыПоля^

Рис. 1.18. Интерфейс и реализация класса

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

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

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

Динамическое создание и уничтожение объектов вьшолняется в процессе работы программы специальными командами.

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

Пример 1.7. Сокрытие реализации класса (класс Файл - продолжение примера 1.5). В соответствии с результатами объектной декомпозиции (см. рис. 1.13). Файл должен реагировать на следующие сообщения: «Открыть», «Добавить запись», «Найти запись».

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

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

38

1.5. Классы

Метод Добавить должен проверять наличие открытого файла и сообщать пользователю о невозможности вьшолнения операции с закрытым файлом. Если же файл открыт, метод должен вьшолнить добавление записей в файл. Для выполнения проверки необходимо хранить информацию об открытии файла, для этого можно использовать специальное поле Состояние_файла, которое также можно объявить в секции реализации.

Метод Найти также вначале должен проверять, открыт ли файл. Если файл открыт, метод выполняет поиск информации в файле. Операции проверки открытия файла выполняются в методах Добавить и Найти идентично, их можно выделить в отделып>1Й метод Проверкаоткрытия, который можно описать в секции реализации.

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

Окончательно для реализации объекта Файл можно предложить класс следующей структуры:

Класс Файл: интерфейс

конструктор Инициализрфовать; метод Открыть (имя файла); метод Добавить (фамилия, телефон); метод Найти (фамилия); деструктор Закрыть_файл;

реализация поле Файловаяпеременная;

поле Состояние_файла; метод Проверкаоткрытия;

Конец описания.

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

В программе должна бьгть использована перемещая типа Файл. Так как файл в программе используется постоянно, соответствующую переменную лучше определять статически.

Передача сообщений объекту будет реализована как вызов соответствующего метода интерфейсной части.

1.6. Основные средства разработки классов

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

39