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

Библиографические замечания


Один из первых языков, поддерживающий универсализацию - LPG [Bert 1983]. Язык Ada сделал эту концепцию широко известной введением механизма родовых пакетов.

Универсализация была также введена в языки формальной спецификации, такие как Z, CLEAR и OBJ-2, на которые были ссылки в лекции 6 по АТД. Родовой механизм, описанный здесь, был построен на основе механизма, представленного в ранней версии Z [Abrial 1980] [Abrial 1980a] и расширенного в [M 1985b].

Если не считать эту книгу, то одним из первых ОО-языков, поддерживающих универсализацию, был DEC's Trellis язык [Schaffert 1986].



Горизонтальное и вертикальное обобщение типа



Рис. 10.1.  Размерности обобщения

Уже изученные механизмы позволяют написать класс, помещенный в центр рисунка - LIST_OF_BOOKS, экземпляр которого представляет список книг. У класса следующие компоненты: put для вставки элемента, remove для удаления элемента, count для подсчета числа элементов и т.д. Очевидны два пути обобщения понятия LIST_OF_BOOKS.

Списки являются специальным видом структур, представляющих контейнеры. Из многих других примеров контейнеров отметим деревья, стеки и массивы. В сравнение со списком LIST_OF_BOOKS, более абстрактным вариантом контейнера является класс SET_OF_BOOKS (множество книг). Более специализированным вариантом является класс LINKED_LIST_OF_BOOKS, определяющий связный список книг - специализированный вариант списка. Три класса задают вертикальную размерность на рисунке - размерность наследования.Списки книг являются, с другой стороны, специальным случаем списков объектов некоторого вида. Из многих других видов отметим списки журналов, списки людей, списки целых чисел. Это горизонтальная размерность на нашем рисунке - размерность универсализации, тема нашего изучения в последующей части этой лекции. Если задать параметр класса, представляющий произвольный тип, то можно не создавать почти идентичные классы, такие как LIST_OF_BOOKS и LIST_OF_PEOPLE, не жертвуя при этом безопасностью, вносимой статической типизацией.

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

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



Использование родового класса


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

sp: STACK [POINT]

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

Предоставление фактических родовых параметров родовому классу для создания типа называется родовым порождением (generic derivation), а полученный в результате класс, такой как STACK [POINT], называют параметрически порожденным классом.

Родовому порождению требуется тип, родовое порождение создает новый тип:

Результат порождения STACK [POINT] является типом.Для получения такого результата, необходим уже существующий тип, используемый в качестве фактического параметра (POINT в примере).

Фактический параметр может быть произвольным типом. Ничто не мешает выбрать тип, который сам по себе параметрически порожден. Предположим, что мы определили другой родовой класс LIST [G], тогда можно определить стек, элементы которого являются списками точек:

slp: STACK [LIST [POINT]]

или, используя STACK [POINT] как фактический родовой параметр, - стек стеков точек:

ssp: STACK [STACK [POINT]]

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



Ключевые концепции




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



Массивы


В заключение этой дискуссии полезно рассмотреть пример контейнерного класса ARRAY, представляющего одномерный массив.



Массивы как объекты


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

ARRAY хороший пример родового класса. Рассмотрим первый набросок этого класса:3)

indexing description: "Последовательность значений одного типа или согласуемых типов,% %доступных через целые индексы в заданном диапазоне" class ARRAY [G] creation make feature make (minindex, maxindex: INTEGER) is -- Размещение массива с границами minindex и maxindex -- (пустой, если minindex > maxindex) do ... end lower, upper, count: INTEGER -- Минимальный и максимальный допустимый индекс; размер массива. put (v: G; i: INTEGER) is -- Присвоить v элементу массива с индексом i do ... end infix "@", item (i: INTEGER): G is -- Элемент с индексом i do ... end end -- класса ARRAY

Для создания массива a с границами m и n, тип объявления которого ARRAY [T] с заданным типом T, нужно выполнить инструкцию создания

create a.make (m, n)

Для задания значений элементов массива используется процедура put: вызов a.put(x, i) присваивает значение x i-ому элементу. Для доступа к элементам можно использовать функцию item (синоним инфиксной операции @, поясняемой позже), например:

x := a.item (i) Вот схема того, как этот класс может быть использован клиентом: pa: ARRAY [POINT]; p1: POINT; i, j: INTEGER ... create pa.make (-32, 101) -- Разместить массив с указанными границами. pa.put (p1, i) -- Присвоить значение p1 элементу с индексом i. ... p1 := pa.item (j) -- Присвоить сущности p1 значение элемента с индексом j.

В обычной нотации (скажем, в Pascal) нужно писать:

pa [i] := p1 вместо pa.put (p1, i)

p1 := pa [i] вместо p1 := pa.item (i)



Необходимость параметризованных классов


Универсализация уже рассматривалась в данной книге, но не применялась для классов. Мы столкнулись с ней при обзоре традиционных подходов к повторному использованию и при изучении математической модели класса - АТД, где была показана необходимость определения параметризированного АТД.



Объявление родового класса


По соглашению родовой параметр обычно, использует имя G (от Generic). Это неформальное правило. Если нужны еще родовые параметры, они будут названы H, I и т.д.

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

indexing description: "Стек элементов произвольного класса G" class STACK [G] feature count: INTEGER -- Количество элементов в стеке empty: BOOLEAN is -- Есть ли элементы? do ... end full: BOOLEAN is -- Стек заполнен? do ... end item: G is -- Вершина стека do ... end put (x: G) is -- Втолкнуть x в стек. do ... end remove is -- Вытолкнуть элемент из стека. do ... end end -- class STACK

Формальный родовой параметр G можно использовать в объявлениях класса не только для результата функций (как в item) и формальных аргументов подпрограмм (как в put), но и для атрибутов и локальных сущностей класса.



Обсуждение: что все-таки не сделано


Основные идеи универсализации уже представлены, но как вы могли заметить, на два важных вопроса не даны ответы.

Первое: в наших усилиях гарантирования безопасности типов мы заняли чересчур консервативную позицию. Конечно, некорректно пытаться втолкнуть круг в стек банковских счетов. Трудно вообразить, какому приложению нужен стек, содержащий точки и банковские счета. Но рассмотрим графическое приложение, для которого вполне естественен стек, содержащий круги, прямоугольники, точки. Такая потребность кажется довольно разумной, но пока мы не можем удовлетворить ее. Система типов, определенная до сих пор, отвергнет вызов figure_stack.put(that_point) если тип figure_stack был объявлен как STACK [FIGURE], а that_point - тип, отличный от FIGURE. Дадим пока имя рассматриваемым структурам и назовем их полиморфными структурами данных (polymorphic data structure). Вызов, стоящий перед нами - как поддержать эти структуры без потери преимуществ безопасности типов.

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

Для обеих этих проблем ОО-метод обеспечивает простые и элегантные решения, оба основанные на комбинировании универсализации и наследования.



Операции над сущностями родового типа


В родовом классе C [G, H, ...] рассмотрим сущность, чей тип - один из формальных родовых параметров, например x типа G. Когда класс используется клиентом для объявления сущностей, G, разумеется, может представлять любой тип. Поэтому любая операция, которую выполняют подпрограммы C над x, должна быть применима ко всем типам. Это ограничение позволяет выполнять только пять видов операций:

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

Корректно использовать сущность x, чей тип задан формальным родовым параметром G, можно следующим образом.

Слева от оператора присваивания x := y, где выражение y также имеет тип G.Справа от оператора присваивания y := x, где сущность y также типа G.В логических выражениях вида x = y или x /= y, где y также типа G.Как фактический аргумент в вызове подпрограммы на месте формальных параметров типа G, или типа ANY.Как цель вызова компонента класса ANY.

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

Случаи (4) и (5) ссылаются на класс ANY. Упомянутый уже несколько раз, этот класс содержит компоненты, наследуемые всеми классами. Поэтому можно быть уверенным, что независимо от фактического типа G при родовом порождении компоненты будут доступны. Компонентами класса ANY являются все основные операции копирования и сравнения объектов: clone, copy, equal, deep_clone, deep_equal и др. Поэтому для x и y формального родового типа G корректно использовать следующие инструкции:

x.copy (y) x := clone (y) if equal (x, y) then ...

Случай (4) разрешает вызов a.f(x) в родовом классе C [G], если f имеет формальный аргумент типа G. В частности, возможна ситуация, когда a может быть типа D [G], где D другой родовой класс. В классе D [G] объявлен компонент f, требующий аргумент типа G, обозначающий в этом случае формальный родовой параметр класса D, а не класса С. (Если предыдущая фраза не совсем понятна, перечитайте ее еще раз, и, надеюсь, она покажется столь же прозрачной2), как горный ручей.)



Правило типизации


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

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

f(a:T):U is ...

Тогда вызов вида x.f(d), появляющийся в произвольном классе B, где x типа C будет мудро корректен по типу, тогда и только тогда, когда:

f доступен классу B, - экспортирован всем классам или множеству классов, включающих B;d принадлежит типу T. Если учитывать возможность наследования, то d может принадлежать потомкам T.Результат вызова имеет тип U. В этом примере предполагается, что компонент f является функцией.

Теперь предположим, что C родовой класс с формальным родовым параметром G имеет компонент:

h (a: G): G is...

Вызов h имеет вид y.h(e), где y сущность, объявленная как

y: C [V]

Тип V - некоторый ранее определенный тип. Теперь правило типизации - двойник неродового правила - требует, чтобы e имело тип V или при наследовании было потомком V. Аналогичное требование к результату выполнения функции h.

Требования правила понятны: V - фактический параметр, заменяющий формальный родовой параметр G параметризованного класса C, поэтому он заменяет все вхождения G при вызове компонент класса. Все предыдущие примеры следовали этой модели: вызов s.put(z) требует параметра z типа POINT, если s типа STACK [POINT]; INTEGER если s типа STACK [INTEGER]; и s.item возвращает результат типа POINT в первом случае и типа INTEGER во втором.



Проблема


Рассмотрим пример стека, но уже не как АТД, а как класс. Мы знаем, как написать класс INTEGER_STACK, задающий стек объектов типа INTEGER. Компоненты будут включать count (число элементов), put (вталкивание элемента), item (элемент в вершине), remove (выталкивание элемента), empty (пустой ли стек?).

Тип INTEGER будет часто использоваться в объявлениях этого класса. Например, это тип аргумента для put и результата для item:

put (element: INTEGER) is -- Втолкнуть элемент (в вершину стека). do ... end item: INTEGER is -- Элемент в вершине стека do ... end

Эти появления типа INTEGER следуют из правила явного объявления, используемого при разработке нотации: всякий раз при введении сущности, обозначающей возможные объекты времени выполнения, необходимо явное указание ее типа, такое как element: INTEGER. Здесь это означает, что необходимо указать тип для запроса item, для аргумента element процедуры put и для других сущностей, обозначающих возможные элементы стека.

Как следствие, придется писать различные классы для каждого сорта стека: INTEGER_STACK, REAL_STACK, POINT_STACK, BOOK_STACK... Все эти стековые классы будут одинаковыми за исключением объявления типов item, element и некоторых других сущностей. Основные операции над стеком не зависят от типа элементов стека и реализуются одинаково. Для всех, заинтересованных в повторном использовании, такое дублирование классов представляется мало привлекательным.

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

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



Проверка типов


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

sc: STACK [CIRCLE]; sa: STACK [ACCOUNT]; c: CIRCLE; a: ACCOUNT.

Тогда в программах этого класса допустимы следующие инструкции:

sc.put (c) -- Втолкнуть круг в стек кругов sa.put (a) -- Втолкнуть счет в стек счетов c := sc.item -- Сущности круг присвоить вершину стека кругов.

Но каждая из следующих инструкций недопустима и будет отвергнута:

sc.put (a); -- Попытка: Втолкнуть счет в стек кругов. sa.put (c); -- Попытка: Втолкнуть круг в стек счетов. c:= sa.item -- Попытка: Дать кругу значение счета.

Это исключает ошибочные операции, подобные попытке вычитания денег из круга.



Размышления об эффективности


Может ли элегантность и простота нанести удар по эффективности выполнения? Одна из причин широкого использования массивов состоит в том, что основные операции - доступ и изменение элемента - проходят быстро. Надо ли платить за каждый вызов подпрограммы при использовании item или put? Нет. То, что ARRAY для ничего не подозревающего разработчика выглядит как нормальный класс, не запрещает компилятору опираться на скрытую информацию. Она позволяет компилятору находить вызовы item и put и переопределять их так, чтобы сгенерировать такой же код, как сделает компилятор Fortran, Pascal или C для эквивалентных инструкций (p1 := pa [i] и pa [i] := p1 в синтаксисе Pascal). Поэтому разработчик получит лучшее: универсальность, общность, упрощенность, простоту использования ОО-решения, сочетаемую с сохранением производительности традиционного решения.Работа компилятора не тривиальна. Как выяснится при изучении наследования, для потомка класса ARRAY возможно переопределить любой компонент класса и эти переопределения могут быть косвенно вызваны через динамическое связывание. Поэтому компилятор должен выполнять тщательный анализ для проверки корректности изменений массива. Для научных приложений, интенсивно использующих массивы, современные компиляторы от ISE и других компаний сегодня могут генерировать код, столь же эффективный, как написанный вручную на C или Fortran.



Родовые АТД


Наш работающий пример АТД, STACK, был объявлен с параметром, как STACK [G]. Любое его использование заставляет специфицировать "фактический родовой параметр", представляющий тип хранимого в стеке объекта. Имя G, используемое в спецификации АТД, - формальный родовой параметр класса. Оно указывает, что элементы стека могут иметь любой возможный тип. При таком подходе можно использовать одну спецификацию для всех возможных стеков. Альтернативой, вряд ли приемлемой, было бы введение множества классов: INTEGER_STACK, REAL_STACK и т.д.

Любые АТД, описывающие контейнеры: множества, списки, матрицы, массивы и многие другие, очевидно, также должны быть родовыми.

Это решение применимо к контейнерам классам, также как к контейнерам АТД.



Родовые классы


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

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

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



Роль типизации


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

Читаемость: явное объявление четко сообщает читателю о том, как предполагается использовать каждый элемент. Это важно как для автора, так и для того, кому нужно понять часть программы, чтобы отладить или расширить ее.Надежность: благодаря явному объявлению типов компилятор сможет найти ошибочные операции еще на этапе компиляции, не допуская их проявления при выполнении. В фундаментальных операциях ОО-вычислений вызов компонента имеет форму x.f (a,..), где х - некоего типа TX. Причины возникновения ошибок могут быть разными: соответствующий класс TX может не иметь метода f; метод может существовать, но быть скрытым; количество аргументов при вызове может не совпадать с объявленным в описании класса; тип а или другого аргумента может не совпадать с ожидаемым. В языке Smalltalk, в котором отсутствует статическая типизация, любая такая ситуация приведет к краху на этапе выполнения с выдачей, например, сообщения: "Message not understood", в то время как компилятор языка с явной типизацией не пропустит ошибочной конструкции.

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

Без учета требований надежности явное объявление типов было бы не нужно так же как универсализация. Остаток этой лекции обращается к языкам со статической типизацией, т.е. языкам, которые требуют объявления каждой сущности и задают правила, позволяющие компиляторам обнаруживать несоответствие типов до выполнения. В не статически типизированных языках, таких как Smalltalk, универсализация не имеет смысла. Язык упрощается, но не защищает от схем вида:

my_stack.put (my_circle) my_account := my_stack.item my_account.withdraw (5000)

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

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



Синонимичная инфиксная операция


Класс ARRAY предоставляет возможность, косвенно относящуюся к вопросам этой лекции, но полезную на практике. Объявление компонента item фактически определяет и его синоним - инфиксную операцию4) следующим образом:

infix "@", item (i: INTEGER): G is...

Здесь задаются два имени компонента: infix "@" и item как синонимы, обозначающие один и тот же компонент, заданный определением.

В общем, объявление компонентов в форме:

a, b, c... "Описание компонента"

рассматривается как краткая форма записи последовательности объявлений:

a "Описание компонента" b "Описание компонента" c "Описание компонента" ...

с одним и тем же "Описанием компонента".

Это применимо как для атрибутов (где "Описание компонента" имеет форму: некоторый_тип), так и для подпрограмм (is тело_программы).

Нотация, применяемая в этом примере для доступа к массиву, достаточно проста. Она совместима с механизмами доступа для других структур, хотя, заметим, инструкция a.item(i) более многословна, чем традиционное a[i], встречающееся с некоторыми вариациями в Pascal, C, Fortran и других языках. Определяя "@" как синоним item, можно превзойти традиционные языки в их собственной игре за краткость записи. Написав a @ i, реализуем мечту, - запись требует на одно нажатие клавиши меньше, чем даже С++!. Заметим снова, что это не специальный механизм языка, но прямое применение общей ОО-концепции, компонент-оператора, скомбинированного с нотацией синонима.



Стоимость универсализации


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

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

Число создаваемых экземпляров шаблона - уже проблема для некоторых пользователей С++. Если пользователь создает List<int>, List<String>, List<Widget> и List<Blidget> (где Widget и Blidget классы, определенные пользователем) и вызывает head, tail и insert для всех четырех объектов, то каждая из этих функций будет создана в четырех экземплярах (из-за родового порождения). Вместо этого широко применимый класс List мог бы создать единственный экземпляр каждой функции применимый для различных типов.5)

Авторы этого предупреждения (С++ эксперты из AT&T, один из них соавтор официальной С++ документации [Ellis 1990]) продолжают предлагать различные способы, позволяющие избежать порождения шаблонов. Но универсализация не предполагает дублирование кода. При хорошо спроектированном языке и хорошем компиляторе можно генерировать единый код компонентов родового класса, так что последующие добавления потребуют минимальных затрат:

времени компиляции;размера сгенерированного кода;времени выполнения;памяти, требуемой для выполнения.

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



Свойства массива


Некоторые замечания о классе.

Подобные классы существуют для массивов большей размерности: ARRAY2 и т. д.Компонент Count может быть реализован и как атрибут и как функция, поскольку count = upper - lower+1. В реальном классе это выражается инвариантом, как объясняется в следующей лекции.Техника утверждений позволяет связывать точные условия согласования с put и item, отражая тот факт, что вызовы допустимы, только если индекс i лежит между lower и upper.Идея описания массивов как объектов (и ARRAY как класс) - хороший пример мощности унификации и упрощения объектной технологии, позволяющей сократить нотацию до минимума и уменьшить количество узкоспециализированных конструкций. Здесь массив рассматривается как обычный пример контейнерной структуры с собственными методами доступа, представленными компонентами put и item.Так как ARRAY - обычный класс, он может участвовать во всем, что в предыдущих лекциях называлось ОО-играми; в частности, другие классы могут быть его наследниками. Класс ARRAYED_LIST, описывающий реализацию абстрактного понятия - списка массивов может быть наследником классов LIST и ARRAY. Подобные конструкции будут рассматриваться далее.

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



Терминология


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

Процесс порождения нового типа, такого как STACK [POINT], из типов POINT и STACK, можно было бы называть созданием экземпляра типа "generic instantiation". Но этот термин мог бы ввести в заблуждение, поскольку в названии неявно предполагается процесс периода выполнения ПО. Заметьте, родовое порождение - статический механизм, действующий на текст программы, а не на ее выполнение.В этой книге термин "параметр" и "аргумент" используются по-разному. Первый для универсальных классов, второй - для подпрограмм. В традиционной программистской терминологии параметры и аргументы чаще всего синонимы.



Типы и классы


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

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

Это приводит к более общему и гибкому понятию. Но за выигрыш в мощности приходится немного пожертвовать простотой: только при небольшом насилии над языком можно продолжать говорить о "компонентах класса T" или о "клиентах T", если x объявлен, как имеющий тип T. Теперь T может быть параметрически порожденным типом C [U] из некоторого родового класса C и некоторого типа U. Конечно, основой типа остается родовой класс C, поэтому насилие над языком приемлемо.

Если требовать буквальной строгости, то терминология следующая. Любой тип T ассоциируется с базовым классом T, поэтому всегда можно говорить о компонентах и клиентах базового класса T. Если T неродовой класс, то он же является и базовым классом. Если T родовое порождение C [U, ...], то C является базовым классом T.

Базовые классы будут использоваться при введении еще одного вида типов, основанного также (как и все остальное в ОО-подходе) на классе, но косвенно: закрепленного типа (см. гл. 16.7).



У10.1 Ограниченная универсализация


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

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



У10.2 Двумерные массивы


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



У10.3 Использование своего формального родового параметра фактически как чужого


Сконструируйте пример, в котором подпрограмма родового класса C [G] вызывает подпрограмму, объявленную в другом родовом классе D [G], имеющую формальный параметр типа G.

  1)

  Полный ответ можно будет найти в приложении B "Genericity versus inheritance".

  2)

  Для проверки прозрачности выполните упражнение У10.3.

  3)

  Улучшенная версия класса рассмотрена в лекции 11

  4)

  Нотация инфиксных операций была введена в лекции 7

  5)

  Martin Carroll, Margaret Ellis, "Reducing Instantiation Time", in "C++ Report", vol. 6, no. 5, July-August 1994, pages 14, 16 and 64.

Автоматическое обновление (automatic update)


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

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

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

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

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



Базовые библиотеки


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

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

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



Бесшовность (seamlessness)


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

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

Эти требования исключают два часто встречающихся случая - оба неудовлетворительных:

Использование ОО-концепций на этапе анализа и проектирования с такой нотацией, которая не может использоваться на этапе программирования. Использование ОО-языка программирования, неподходящего для этапа анализа и проектирования.

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



Библиографические ссылки и объектные ресурсы


Введение в ОО-критерии - это то место, где стоит привести список работ, дающих хорошие введения в объектную технологию в целом.

[Walden 1995] обсуждает самые важные проблемы объектной технологии, обращая особое внимание на анализ и проектирование, эта книга является, вероятно, лучшим справочным руководством по этому вопросу.

[Page-Jones 1995] дает отличный обзор метода.

[Cox 1990] (первое издание относится к 1986 году) основывается на несколько другом взгляде на объектную технологию; книга послужила распространению ОО-концепций среди широкой публики.

[Henderson-Sellers 1991] (второе издание готовится) дает краткий обзор ОО-идей. Книга предназначена для людей, которых их компания просит "пойти и посмотреть, что это такое объектное программирование", содержит готовые для копирования диапозитивные оригиналы, в некоторых случаях очень ценные. Еще один обзор - это [Eliens 1995].

Словарь Объектной Технологии [Firesmith 1995] дает обширный справочный материал по многим аспектам метода.

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

Книга [M 1995] выросла из лекции, первоначально предназначенной для данной книги, и стала полноправной книгой, в которой объектная технология обсуждается с позиций управляющего персонала. Она начинается небольшой технической презентацией, использующей профессиональные термины, и далее дает анализ вопросов менеджмента (жизненный цикл, управление проектами, политика повторного использования). Еще одна книга с управленческим уклоном, [Goldberg 1995], дает дополнительную перспективу многих важных тем. [Baudoin 1996] делает акцент на вопросах жизненного цикла и важности стандартов.

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

Simula BEGIN [Birtwistle 1973] (еще два автора являются создателями языка - Nygaard и Dahl.) Smalltalk-80: Язык и его реализация [Goldberg 1983]. Язык программирования C++, второе издание [Stroustrup 1991].

Совсем недавно некоторые начальные учебники по программированию стали использовать ОО-идеи с самого начала, поскольку нет причин позволять "онтогенезу повторять филогенез". Нет необходимости, чтобы бедные студенты, как их предшественники, прошли через всю историю колебаний и ошибок, пока не доберутся до правильных идей. Первый такой текст (насколько я знаю) был [Rist 1995]. Другая хорошая книга, отвечающая тем же потребностям - это [Wiener 1996]. На следующем уровне - учебники для второго курса по программированию. Обсуждение структур данных и алгоритмов, основанное на нотации этой книги - вы найдете в [Gore 1996] и [Wiener 1997]; [Jezequel 1996] представляет принципы ОО-инженерии ПО. Преподавание технологии обсуждается также в лекции 11 курса "Основы объектно-ориентированного проектирования".

Группа новостей Usenet comp.object, на нескольких сайтах сети, является естественной площадкой обсуждения многих вопросов объектной технологии. Как и все подобные форумы, это смесь хорошего, плохого и ужасного. Раздел Объектной Технологии в Computer (IEEE), который я редактирую с его начала в 1995 году, часто помещает колонки ведущих экспертов.

Журналы, посвященные Объектной Технологии:

Journal of Object-Oriented Programming (первый журнал в этой области, в центре которого технические обсуждения, но они предназначены для широкой публики), Object Magazine (более общего диапазона, с некоторыми статьями для менеджеров), Objekt Spektrum (на немецком языке), Object Currents (онлайн), адрес http://www.sigs.com.Theory and Practice of Object Systems, архивный журнал. L'OBJET (на французском языке), адрес http://www.tools.com/lobjet.

Основные международные конференции по объектному ориентированию:

OOPSLA (ежегодная, USA или Canada, см. http://www.acm.org); Object Expo (различное время и разные места, см. http://www.sigs.com); и TOOLS (Технология ОО-языков и систем), организуемая ISE три раза в год (USA, Europe, Pacific), см. материалы по адресу: http://www.tools.com, также является общим ресурсом объектной технологии и вопросов, обсуждаемых в этой книге.


Библиотеки


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



Быстрое обновление (fast update)


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

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

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



Быстрый просмотр (browsing)


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

В этом и состоит задача просмотра. Типичные хорошие возможности просмотра включают: поиск классов - клиентов, поставщиков, потомков, предков; поиск всех переопределений компонента; поиск исходного объявления переопределенного компонента. (Определение: S - поставщик С, если С - клиент S. Термин "клиент класса" пояснен выше.)

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



Динамическое связывание


Сочетание последних двух механизмов, переопределения и полиморфизма, непосредственно предполагает следующий механизм. Допустим, есть вызов, целью которого является полиморфная сущность, например сущность типа BOAT вызывает компонент turn. Различные потомки класса BOAT, возможно, переопределили этот компонент различными способами. Ясно, что должен существовать автоматический механизм, гарантирующий, что версия turn всегда соответствует фактическому типу объекта, вне зависимости от того, как объявлена сущность. Эта возможность называется динамическим связыванием (dynamic binding).

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

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

Динамическое связывание оказывает большое влияние на структуру ОО-приложения, поскольку дает возможность разработчикам писать простые вызовы, например объект my_boat вызывает компонент turn. В действительности, данный вызов означает несколько возможных вызовов, зависящих от соответствующих ситуаций времени выполнения. Это упраздняет необходимость многих повторных проверок (является ли объект merchant_ship? Является ли он sports_boat?), наводняющих программные продукты, создаваемые при обычных подходах.



До какой степени мы должны быть догматичными?


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

Только вы, мой читатель, можете ответить на этот вопрос применительно к собственному контексту. Вот несколько причин, по которым может быть необходим компромисс:

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

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



Документация


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

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



Дублируемое наследование (Repeated inheritance)


При множественном наследовании возникает ситуация дублируемого наследования (repeated inheritance), когда некоторый класс многократно становится наследником одного и того же класса, проходя по разным ветвям наследования:


Рис. 2.1.  Дублируемое наследование

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

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



Единичное наследование (single inheritance)


Разработка ПО включает создание большого числа классов, многие из которых являются вариантами ранее созданных классов. Для управления потенциальной сложностью такой системы необходим механизм классификации, известный как наследование. Класс A будет наследником (heir) класса B, если он встраивает (наследует) компоненты класса B в дополнение к своим собственным. Потомок (descendant)- это прямой или непрямой наследник; обратное понятие - предок (ancestor).

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

Наследование - одно из центральных понятий ОО-метода; оно оказывает большое влияние на процесс разработки ПО.



Графика и пользовательские интерфейсы


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

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



Категории


Набор критериев делится на три части:

Метод и язык (Method and Language) : эти два почти не различимые аспекта охватывают мыслительные процессы и нотацию, использующуюся для анализа, проектирования и программирования ПО. Заметьте, что (особенно в объектной технологии) термин "язык" относится не только к языку программирования в строгом смысле, но также и к языкам анализа и проектирования и используемой в них нотации, текстовой или графической. Реализация (Implementation) и Среда (Environment) : критерии в этой категории описывают основные свойства инструментария, позволяющего разработчикам применять ОО-идеи. Библиотеки (Libraries) : объектная технология основана на повторном использовании компонентов ПО. Критерии в этой категории описывают как наличие базовых библиотек, так и механизмы, необходимые для их использования и создания новых библиотек.

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



Классы


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

Понятие класса должно быть центральной концепцией метода и языка.



Классы как модули


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

Здесь опять велика роль классов. Класс описывает не только тип объектов, но и модульную единицу. В чистом ОО-подходе:

Классы должны быть единственным видом модулей.

В частности, исчезает понятие главной программы, а подпрограммы не существуют как независимые модульные единицы (они могут появляться только как часть классов). Нет необходимости в "пакетах", используемых в таких языках, как Ada. Хотя удобно в целях управления группировать классы в административные единицы, называемые кластерами.



Классы как типы


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

Каждый тип должен быть основан на классе.

Даже базовые типы, такие как INTEGER и REAL, можно рассматривать как классы; обычно такие классы являются встроенными.



Механизмы индексации в библиотеках


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

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



Механизмы эволюции библиотек


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

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



Метод и язык


Первый набор критериев относится к методу и поддерживающей его нотации.



Множественное наследование (Multiple inheritance)


Часто необходимо сочетать различные абстракции. Рассмотрим класс, моделирующий понятие "младенец". Его можно рассматривать как класс "человек" с компонентами, связанными с этим классом. Его же можно рассматривать и более прозаично - как класс "элемент, подлежащий налогообложению", которому положены скидки при начислении налогов. Наследование оправдано в обоих случаях. Множественное наследование (multiple inheritance) - это гарантия того, что класс может быть наследником не только одного класса, но многих, если это концептуально оправдано.

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

Класс должен иметь возможность быть наследником нескольких классов.

Конфликты имен при наследовании разрешаются адекватным механизмом.

Решение, разработанное в этой книге, основано на переименовании конфликтующих компонентов у класса наследника.



Обработка исключений (Exception handling)


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

Для создания надежного ПО необходимо иметь возможность восстановления нормального хода вычислений. Это является целью механизма обработки исключений.

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

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



Ограниченная универсальность (Constrained genericity)


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

Родовой класс SORTABLE_LIST описывает списки; он содержит компонент sort, сортирующий элементы списка в соответствии с заданным отношением порядка. Параметр этого родового класса задает тип элементов списка. Но этот тип не может быть произвольным: он должен поддерживать отношение порядка. Фактический родовой параметр должен быть потомком библиотечного класса COMPARABLE, описывающего объекты, снабженные отношением порядка. Ограниченная универсальность позволяет объявить наш родовой класс следующим образом: SORTABLE_LIST [G -" COMPARABLE] .

Механизм универсальности должен поддерживать форму ограниченной универсальности.



О критериях


Рассмотрим выбор критериев, позволяющих оценить объектную ориентированность системы (objectness).



Отложенные (deferred) свойства и классы


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

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

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

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



Переопределение (redefinition)


Когда класс является наследником другого класса, может потребоваться изменить реализацию или другие свойства некоторых наследованных компонент. Класс SESSION, управляющий сеансами пользователей в операционной системе, может иметь компонент terminate, выполняющий чистку в конце сеанса. Его наследником может быть класс REMOTE_SESSION, управляющий сеансом удаленного компьютера в сети.

Если завершение удаленного сеанса требует дополнительных действий, таких как, например, уведомление удаленного компьютера, класс REMOTE_SESSION переопределит компонент terminate.

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

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



Полиморфизм


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

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

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

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



Продолжение просмотра


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

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



Реализация и среда


Мы подошли к важным свойствам среды разработки, поддерживающей создание ОО-ПО.



Скрытие информации (information hiding)


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

Механизм, делающий определенные компоненты недоступными для клиентов, называется скрытием информации.

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

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

Автор класса должен иметь возможность указать, что компонент доступен: всем клиентам, ни одному клиенту или избранным клиентам.

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



Статическая типизация (static typing)


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

Чтобы гарантировать корректное выполнение, язык должен быть типизирован. Это означает, что он отвечает нескольким правилам совместимости:

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

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

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



Универсальность (genericity)


Для того чтобы типизация была практичной, необходимо иметь возможность определять классы с параметрами, задающими тип. Такие классы известны как родовые. Родовой класс LIST [G] описывает списки элементов произвольного типа G - "формальным родовым параметром".

Классы, задающие специальные списки, будут его производными, например LIST [INTEGER] и LIST [WINDOW] используют типы INTEGER и WINDOW в качестве "фактических родовых параметров". Все производные классы разделяют один и тот же текст родового класса.

Должна существовать возможность создания классов с формальными родовыми параметрами, представляющими произвольные типы.

Эта форма параметризации типа называется неограниченной универсальностью. Дополнительной возможностью, описанной ниже, является ограниченная универсальность, использующая понятие наследования.



Управление памятью (memory management) и сборка мусора (garbage collection)


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

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

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

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



Утверждения (Assertions)


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

Утверждения - предусловия и постусловия программ класса и инварианты классов - играют эту роль.

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

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

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



Вычисления, основанные на компонентах


В ОО-вычислениях существует только один базовый вычислительный механизм. Есть некоторый объект, всегда являющийся (в силу предыдущего правила) экземпляром некоторого класса, и вычисление состоит в том, что данный объект вызывает некоторый компонент этого класса. Например, для показа окна на экране вызывается компонент display объекта, представляющего окно, - экземпляра класса WINDOW. Компоненты могут иметь аргументы: для увеличения зарплаты работника e на дату d, на n долларов, вызывается компонент raise объекта e, с аргументами n и d.

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

Вызов компонента должен быть основным механизмом вычисления.

Класс, содержащий вызов компонента класса C, называют клиентом класса С .

Вызов компонента иногда называют передачей сообщения (message passing) ; по этой терминологии вышеприведенный вызов будет описываться как передача объекту e сообщения: "повысить вашу плату" с аргументами d и n.



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


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

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

Операция попытка присваивания (assignment attempt) удовлетворяет этим требованиям. Это условная операция: она пытается присоединить объект к сущности; если при выполнении операции тип объекта соответствует типу сущности, то она действует как нормальное присваивание; в противном случае сущность получает специальное значение void. Итак, можно управлять объектами, тип которых не известен наверняка, не нарушая безопасности системы типов.

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



Живучесть (persistence)


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

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

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

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