книги / Объектно-ориентированное программирование

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

разделение времени может выполняться либо разрабатываемой системой (как в MS DOS), либо используемой ОС (как в системах Windows).

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

Различают:

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

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

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

памяти между сеансами работы программы.

Все указанные выше принципы в той или иной степени реализованы в различных версиях объектно-ориентированных языков.

Объектно-ориентированные языки программирования. Язык считается объектно-ориентированным, если в нем реализованы первые четыре из рассмотренных семи принципов.

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

Несмотря на то, что принципиально ООП возможно на многих языках программирования, желательно для создания объектно-ориентированных программ использовать объектно-ориентированные языки, включающие специальные средства, например, Borland Pascal (начиная с версии 5.5), C++, Delphi и т.д.

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

Самая простая объектная модель использована при разработке Borland Pascal 7.0. Она специально создавалась для облегчения перехода программистов на использование технологии ООП и не поддерживает абстракции метаклассов, почти не содержит специальных средств сокрытия реализации объектов. Но даже в таком варианте она позволяет создавать достаточно сложные системы. Объектные модели остальных языков являются практически полными.

Особое место занимают объектные модели Delphi и C++Builder. Эти модели обобщают опыт ООП для MS DOS и включают некоторые новые средства, обеспечивающие эффективное создание более сложных систем. На базе этих моделей созданы визуальные среды для разработки приложений Windows. Сложность программирования под Windows удалось существенно

22

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

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

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

1.2. Основные принципы и этапы объектно-ориентированного программирования

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

наследованием свойств [2].

Взаимодействие программных объектов в такой системе осуществляется путем передачи сообщений (рис. 1.6).

П р и м е ч а н и е . Такое представление программы впервые было использовано в языке имитационного моделирования сложных систем Simula, появившемся еще в 60-х годах. Естественный для языков моделирования способ представления программы получил развитие в другом специализированном языке моделирования - языке Smalltalk (70-е годы), а затем был использован в новых версиях универсальных языков программирования, таких как Pascal, C++, Ада, Modula.

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

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

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

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

Рассмотрим, что представляет собой каждый принцип.

18

1.2. Основные принципы и этапы ООП

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

Т а б л и ц а 1.1. Сравнительные характеристики моделей О О П в

некоторых средах программирования

23

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

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

Рассмотрим эти этапы.

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

П р о е к т и р о в а н и е . Различают:

логическое проектирование, при котором принимаемые реш ения практически не зависят от условий эксплуатации (операционной системы и используемого оборудования);

физическое проектирование, при котором приходится принимать во внимание указанные факторы.

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

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

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

24

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

Использование поэтапной реализации сущ ественно упрощ ает тестирование и отладку программного продукта.

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

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

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

Рассмотрение основных приемов объектного подхода начнем с объектной

декомпозиции.

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

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

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

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

Процесс представления предметной области задачи в виде совокупности

25

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

объектов, обмениваю щ ихся сообщ ениям и, назы вается объектной декомпозицией.

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

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

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

Процесс работы бензоколонки с тремя заправочными местами можно представить в виде диаграммы (рис. 1.7).

На этой диаграмме tl, t2, t 3 , ... - моменты времени, когда подъезжает очередная автомашина; Колонка 1 - Колонка 3 - заправочные места.

Прямоугольник соответствует времени заправки автомашины (на

26

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

диаграммах колонок) или времени ожидания в очереди (на диаграмме очереди). Номера машин указаны внутри прямоугольников.

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

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

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

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

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

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

Модель очереди, получая управление, будет отслеживать изменение размера очереди во времени. На основании этих данных при завершении моделирования можно определить среднюю длину очереди.

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

27

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

Занять колонку

Рнс. 1.8. Диаграмма объектов имитационной модели бензоколонки

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

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

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

Пример 1.3. Декомпозиция объекта (Блок колонок). Модель блока колонок должна включать модели колонок и некоторый управляющий объект, который назовем Монитором. Монитор, получив сообщение, интерпретирует его и при необходимости генерирует сообщения моделям колонок. Например, получив сообщение-запрос о времени освобождения колонки, монитор отправит сообщения-запросы колонкам и выберет минимальное время из сообщенных колонками. Это минимальное время он вернет модели в качестве ответа на ее запрос. Получив сообщение о наступлении времени освобождения колонки, Монитор отправит соответствующие сообщения модели очереди и освобождаемой колонке (рис. 1.9).

28

Рис. 1.9. Объектная декомпозиция Блока колонок:

1 - когда освободится колонка? 3 - колонка свободна?

2 - освободить колонку; 4 - занять колонку

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

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

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

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

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

29

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

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

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

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

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

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

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

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

30