Динамические структуры, структуры объект и программирование с использованием этих объктов

end

содержит прямой цикл ( PERSON1 - клиент PERSON1 ).

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

class PERSON2 feature

   mother, father: PERSON2

end

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

Взгляд  на структуру объектов периода выполнения

На основе предшествующего  рассмотрения выясняется в первом приближении  структура ОО-системы в процессе выполнения.

 
Рис. 8.8.  Возможная структура объектов во время выполнения

Система состоит  из нескольких объектов с различными полями. Некоторые поля содержат значения базовых типов, а другие являются пустыми или присоединенными  ссылками на другие объекты. Каждый объект является экземпляром некоторого типа, основанного на классе (на рисунке  тип указывается под объектом). Некоторые типы представлены единственным экземпляром, но гораздо чаще присутствует несколько экземпляров одного типа. На рис.8.8 типTYPE1 представлен двумя экземплярами, остальные - единственным. Некоторые объекты содержат поля только ссылочного типа (экземпляр TYPE4 ) или только базовых типов (экземпляр TYPE5 ). Могут присутствовать прямые или косвенные циклические ссылки (верхнее поле экземпляра TYPE2, по часовой стрелке от нижнего экземпляра TYPE1 ).

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

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

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

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

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

Объекты как средство моделирования

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

Четыре  мира программной  разработки

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

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

Соотношения между  этими мирами представлены на рис.8.9.

 
Рис. 8.9.  Формы и их экземпляры

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

Это различие невыразимо ни в стандартных математических определениях понятия "отношение", ни в программистской терминологии, например в теории реляционных баз  данных. Если ограничиться бинарными  отношениями, то и в математике и  в теории баз данных отношение  определяется как множество пар  в форме <x, y>, где x и y являются элементами заданных множеств TX и TY. В терминах программирования все x относятся к типу TX, а все y - к типу TY. Будучи пригодными для математиков, эти определения не подходят для целей моделирования, поскольку не позволяют различать абстрактные отношения и отношения конкретных экземпляров. При моделировании системы отношение "любит" имеет свои общие и абстрактные свойства, совершенно не зависящие от записи того, кто кого любит в конкретной группе людей в некоторый момент времени.

Реальность: "седьмая вода на киселе"

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

Такое разграничение  проводится не всегда. Во многих дискуссиях используется выражение "моделирование  реального мира"; аналогичные  высказывания содержат и книги по ОО-анализу. Однако говорить о "реальности" применительно к программной  системе ошибочно, по крайней мере, по четырем причинам.

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

Во-вторых, понятие  реального мира рушится в нередких ситуациях, когда ПО предназначено для разрешения проблем ПО. Рассмотрим компилятор C, написанный на Pascal. Для него "реальными" объектами являются программы на C. Насколько эти программы более реальны, чем сам компилятор? Это наблюдение применимо и к другим системам, работающим с объектами, существующими только в компьютере

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

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

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

В идеальном случае программная система приходится соответствующей реальности лишь "седьмой  водицей на киселе" (cousin twice removed).

Работа  с объектами и  ссылками

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

Динамическое  создание и повторное  связывание

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

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

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

Инструкция  создания

Рассмотрим создание экземпляра класса BOOK3. Это возможно только с помощью подпрограммы класса, являющегося клиентом BOOK3, как, например:

class QUOTATION feature

   source: BOOK3

   page: INTEGER

   make_book is

         -- Создание объекта BOOK3 и присоединение  его к source.

      do

         ... См. ниже ...

      end

end

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