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

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

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

Определение класса

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

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

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

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

Термин "объект" появляется как побочный продукт определения "класса". Объект это просто экземпляр некоторого класса.

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

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

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

Некоторые ОО-языки, особенно Smalltalk, для выхода из рассмотренной ситуации используют понятие метакласс (metaclass). Метакласс - это класс, экземпляры которого сами являются классами. В романе "Имя Розы", отрывок из которого приведен в эпиграфе к данной лекции, встречается понятие "знаки знаков". По сути, это и есть неформальное определение метаклассов.

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

[x]. Метаклассы можно использовать для задания свойств, доступных многим или всем классам. Тот же результат можно достичь, создавая семейство классов, наследников общего предка - класса ANY, содержащего объявления универсальных свойств.

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

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

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

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

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

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

Модули - это структурные единицы, из которых состоит программа. Различные виды модулей, такие как подпрограммы и пакеты, рассматривались в одной из предыдущих лекций (см. лекция 3). Независимо от конкретного выбора той или иной модульной структуры, модуль всегда рассматривается как синтаксическая концепция. Отсюда следует, что разбиение на модули влияет лишь на форму записи исходных текстов программ, но не определяет их функциональность. В самом деле, принципиально можно написать программу Ada в виде единственного пакета, или программу Pascal как единую основную программу. Безусловно, такой подход не рекомендуется, и любой компетентный программист будет использовать модульные возможности языка для деления программы на обозримые и управляемые части. Но если взять существующую программу, например на Паскале, то всегда можно собрать воедино все модули и получить работоспособную программу с эквивалентной семантикой. (Присутствие рекурсивных подпрограмм делает этот процесс менее тривиальным, но не оказывает принципиального влияния на данную дискуссию.) Таким образом, деление на модули диктуется принципами управления проектами, а не внутренней необходимостью.

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

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

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

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

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

Объектный принцип

Каждый объект является экземпляром некоторого класса

Объектный принцип будет распространяться не только на составные объекты, определяемые разработчиками (такие как структуры данных, содержащие несколько полей), но и на базовые объекты - целые и действительные числа, булевы значения и символы, которые будут рассматриваться как экземпляры предопределенных библиотечных классов (INTEGER, REAL, DOUBLE, BOOLEAN, CHARACTER).

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

[x]. Всегда желательно иметь простую и универсальную схему, нежели множество частных случаев. Предлагаемая система типов полностью опирается на понятие класса.

[x]. Описание базовых типов как абстрактных структур данных и далее как классов является простым и естественным. Нетрудно представить, например, определение класса INTEGER с функциональностью включающей арифметические операции, такие как "+", операции сравнения, такие как "=" и ассоциированные свойства, следующие из соответствующих математических аксиом.

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

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

Построение непротиворечивой и универсальной системы типов требует комплексного применения ряда важных ОО-методик, которые будут рассмотрены позже. К их числу относятся расширяемые классы, гарантирующие корректное представление простых значений; инфиксные и префиксные операции, обеспечивающие возможность использования привычного синтаксиса (a < b или -a вместо неуклюжих конструкций a.less_than (b) или a.negated); ограниченная универсализация, необходимая для описания классов, адаптируемых к типам со специфическими операциями. Например, класс MATRIX может представлять целочисленные матрицы, а также матрицы, элементами которых являются числа других типов.

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

Пример использует представление точки в двумерной графической системе:

Рис. 7.1.  Точка и ее координаты

Для определения типа POINT как абстрактного типа данных потребуется четыре функции-запроса: x, y, ρ, θ. (В текстах подпрограмм для двух последних функций будут использоваться имена rho и theta). Функция x возвращает абсциссу точки (горизонтальную координату), y - ординату (вертикальную координату), ρ - расстояние от начала координат, θ - полярный угол, отсчитываемый от горизонтальной оси. Значения x и y являются декартовыми, а ρ и θ - полярными координатами точки. Другой полезной функцией является distance, возвращающая расстояние между двумя точками.

Далее спецификация АТД будет содержать такие команды, как translate (перемещение точки на заданное расстояние по горизонтали и вертикали), rotate (поворот на определенный угол вокруг начала координат) и scale (уменьшение или увеличение расстояния до начала координат в заданное число раз).

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

x: POINT REAL

translate: POINT × REAL × REAL POINT

и одна из аксиом:

x (translate (p1, a, b)) = x (p1) + a

утверждающая, что для произвольной точки p1 и действительных значений a и b при трансляции точки на <a, b> абсцисса увеличивается на a.

Читатель, если пожелает, может самостоятельно завершить спецификацию АТД. В дальнейшей дискуссии подразумевается, что вы понимаете, как устроен данный АТД, вне зависимости от того, написали ли вы его полную формализацию или нет. Сосредоточим внимание на реализации АТД - классе.

Любой абстрактный тип данных и POINT в частности характеризуется набором функций, описывающих операции применимые к экземплярам АТД. В классе, реализующем АТД, функции становятся компонентами (features) - операциями, применимыми к экземплярам класса.

В лекции 6 было показано, что в АТД существуют функции трех видов: запросы (queries), команды (commands) и конструкторы (creators). Для компонентов классов необходима дополнительная классификация, основанная на том, каким образом реализован данный компонент - в пространстве или во времени (by space or by time). (См. "Категории функций", лекция 6)

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

Рис. 7.2.  Представление точки в декартовых координатах

Если p1 является такой точкой, то получение значений x и y сведется просто к просмотру соответствующих полей данной структуры. Однако определение значений ρ и θ требует вычисления выражения √(x² + y²) для ρ и arctg (y/x) для θ (при условии ненулевого x).

Использование полярной системы координат (рис. 7.3) приводит к противоположной ситуации. Теперь ρ и θдоступны просто как значения полей, а определение x и y возможно после простых вычислений (ρ cosθ, ρ sinθ, соответственно).

Рис. 7.3.  Представление точки в полярных координатах

Приведенный пример указывает на необходимость рассмотрения компонентов двух видов:

[x]. Некоторые компоненты представлены в пространстве и, можно сказать, ассоциируются с некоторой частью информации каждого экземпляра класса. Они называются атрибутами (attributes). Для точки, представленной в декартовых координатах, атрибутами являются x и y, а в полярных координатах в роли атрибутов выступают rho и theta.

[x]. Другие компоненты представлены во времени, и для доступа к ним требуется описать некоторые вычисления (алгоритмы), применимые далее ко всем экземплярам данного класса. В дальнейшем они называются подпрограммами или методами класса (routines). В декартовом представлении точек - rho и theta это подпрограммы, а x и y выступают в качестве подпрограмм при использования полярных координат.

Вторая категория - подпрограммы - нуждается в дальнейшей дополнительной классификации. Часть подпрограмм возвращает результат, и их называют функциями (functions). В приведенном примере функциями являются x и y в представлении в полярных координатах, в то время как rho и theta - функции в декартовых координатах, все они возврвщают результат типа REAL. Подпрограммы, не возвращающие результат, соответствуют командам в спецификации АТД и называются процедурами (procedures). Например, класс POINT содержит процедуры translate, rotate и scale.

На рис. 7.4 дана рассмотренная выше классификация, представленная в виде дерева:

Рис. 7.4.  Классификация компонентов класса по их роли

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

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

Рис. 7.5.  Классификация компонентов класса по способу реализации

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

Ответ зависит от того, с какой точки зрения рассматривать данную проблему - разработчика, автора данного класса POINT или клиента, создавшего класс, использующий POINT. Для разработчика разница между атрибутами и функциями принципиально важна и имеет смысл. Ему необходимо принимать решения о том, какие компоненты будут реализованы как данные в памяти и какие будут доступны в результате вычислений. Но заставлять клиента осознавать эту разницу, было бы серьезной ошибкой. Клиент должен обращаться к значениям x или ρ для точки p1, не заботясь и не имея информации о том, как реализованы соответствующие запросы.

Решение проблемы дает принцип унифицированного доступа (Uniform Access principle), введенный в дискуссии о модульности (лекция 3). Принцип декларирует, что клиент должен иметь возможность доступа к свойствам объекта, используя одинаковую нотацию, вне зависимости от того, как это свойство реализовано - в памяти или как результат вычислений (в пространстве или во времени, в виде атрибута или подпрограммы). Этому важному принципу необходимо следовать при разработке нотации для обращения к компонентам класса. Так выражение, обозначающее значение компонента x объекта p1 будет всегда записываться в виде:

p1.x

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

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

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

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

indexing

description: "Точка на плоскости"

class POINT feature

x, y: REAL

-- Абсцисса и ордината

rho: REAL is

-- Расстояние до начала координат (0, 0)

do

Result := sqrt (x^2 + y^2)

end

theta: REAL is

-- Полярный угол

do

-- Предлагается реализовать в качестве упражнения (упр. У7.3)

end

distance (p: POINT): REAL is

-- Расстояние до точки p

do

Result := sqrt ((x - p.x)^2 + (y- p.y)^2)

end

translate (a, b: REAL) is

-- Перемещение на a по горизонтали, b по вертикали

do

x := x + a

y := y + b

end

scale (factor: REAL) is

-- Изменение расстояния до начала координат в factor раз

do

x := factor * x

y := factor * y

end

rotate (p: POINT; angle: REAL) is

-- Поворот вокруг p на угол angle

do

-- Предлагается реализовать в качестве упражнения (упр. У7.3)

end

end

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

Класс в основном состоит из предложения, перечисляющего различные компоненты, вводимого ключевым словом feature. Кроме того, присутствует предложение indexing дающее общее описание (description), полезное для понимания функциональности класса, но никак не влияющее на семантику исполнения. Позднее будут рассмотрены три дополнительных предложения: inherit - для наследования; creation - при необходимости использования специального конструктора; invariant - для объявления инвариантов класса. Будет рассмотрена также возможность включения в класс двух или более предложений feature.

Класс POINT демонстрирует ряд приемов, которые будут использованы в последующих примерах. Необходимо оговорить основные соглашения.

Компоненты x и y объявлены как относящиеся к типу REAL без ассоциированного алгоритма, следовательно, они являются атрибутами. Все остальные компоненты содержат конструкции вида

is

do

... Инструкции ...

end

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

rho: REAL is ...

Это определяет их как функции. Две другие подпрограммы, translate и scale, не возвращают результата (объявление не завершается конструкцией: T, где T некоторый тип) и, соответственно, являются процедурами.

Поскольку x и y являются атрибутами, а rho и theta функциями, данный конкретный класс использует для представления точки декартову систему координат.

Тело подпрограммы (предложение do) представляет собой последовательность инструкций. Можно разделять последовательные инструкции и объявления точкой с запятой в традициях Algol-Pascal, но это не обязательно. Далее с целью упрощения точка с запятой будет опускаться между элементами на отдельных строках, но всегда будет использоваться как разделитель нескольких инструкций или объявлений в одной строке. (См. "Война вокруг точек с запятой", лекция 8 курса "Основы объектно-ориентированного проектирования")

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

Другое соглашение о нотации касается использования комментария к заголовку подпрограммы. Уже отмечалось, что комментарии начинаются с двух последовательных тире "--". Они могут размещаться в любом месте, где, по мнению автора, дополнительные разъяснения могут принести пользу. Особую роль играет комментарий к заголовку (header comment). В соответствии с общим стилевым правилом он должен помещаться в начале каждой подпрограммы после ключевого слова is с отступом как в примере класса POINT. Комментарий к заголовку должен кратко отражать назначение подпрограммы.

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

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

index_word: index_value, index_value, ...

где index_word - произвольный идентификатор (элемент индексирования), а каждое значение index_value - произвольный элемент языка (идентификатор, целое число, строка и т.д.) (См. "Заметки об indexing", лекция 4).

Это дает два преимущества:

[x]. Читатели исходного текста получают сводку свойств класса без необходимости рассмотрения деталей.

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

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

Предложения indexing и комментарии к заголовку являются иллюстрацией правильного применения принципа самодокументирования (Self-Documentation principle): везде, где это возможно, документация модуля должна размещаться непосредственно в самом модуле. (См. "Самодокументирование", лекция 3)

Для понимания текстов функций rho, theta и distance в классе POINT необходимо еще одно соглашение.

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

Например, тело функции rho содержит следующее присваивание

Result := sqrt (x^2 + y^2)

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

При любом вызове функции в качестве результата будет возвращаться последнее присвоенное Result значение. Оно всегда определено благодаря правилам языка (они будут детально рассмотрены позже), требующим обязательной инициализации Result в начале каждой подпрограммы путем присваивания значения, предопределенного типом T. Для типа данных REAL инициализирующее значение равно нулю и следующая функция:

non_negative_value (x: REAL): REAL is

-- Возвращает значение аргумента при x>0; ноль при x<=0

do

if x > 0.0 then

Result := x

end

end

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

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

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

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

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

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

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

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

class POINT inherit

ARITHMETIC

feature

... Остальная часть кода без изменений ...

end

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

Обратимся опять к тексту одной из подпрограмм, процедуре translate:

translate (a, b: REAL) is

-- Перемещение на a по горизонтали, b по вертикали

do

x:= x + a

y:= y + b

end

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

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

Иногда возникает необходимость явного обращения к текущему экземпляру. Зарезервированное слово

Current

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

distance (p: POINT): REAL is

-- Расстояние до точки p

do

if p /= Current then

Result := sqrt ((x - p.x)^2 + (y- p.y)^2)

end

end

Здесь /= операция неравенства. В соответствии с сформулированным ранее правилом инициализации условная инструкция не нуждается в части else, поскольку результат равен нулю при p = Current.

Тем не менее, в большинстве случаев текущий экземпляр подразумевается, и нет необходимости обращаться к Current по имени. Так ссылка на x в теле translate и других подпрограмм обозначает "значение x текущего экземпляра" без дополнительного уточнения.

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

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

Существуют лишь две возможности использования класса, например, POINT. Первый способ - наследование, будет детально рассмотрен позднее. Для реализации второй возможности необходимо создать класс, являющийся клиентом (client) класса POINT. (Наследованию посвящены лекции 14-16.)

Чтобы стать клиентом класса S, простейший и наиболее общий путь - объявить сущность типа S.

Определение: клиент, поставщик

Пусть S некоторый класс. Класс C называется клиентом (client) S, если содержит объявление сущности a: S. Класс S называется поставщиком (supplier) C.

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

Например, наличие в классе POINT объявлений x, y, rho, theta и distance делает этот класс клиентом класса REAL. Напротив, другие классы могут стать клиентами POINT. Например:

class GRAPHICS feature

p1: POINT

...

some_routine is

-- Выполнение неких действий с p1.

do

... Создание экземпляра POINT и присоединение его к p1 ...

p1.translate (4.0, -1.5) --**

...

end

...

end

Перед выполнением инструкции помеченной "--**" атрибут p1 принимает значение, соответствующее конкретному экземпляру класса POINT. Предположим, что этот объект представляет точку, совпадающую с началом координат x = 0, y = 0:

Рис. 7.6.  Начало координат

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

Отмеченная звездочками инструкция

p1.translate (4.0, -1.5)

заслуживает внимательного изучения, поскольку представляет собой первый пример использования базового механизма ОО-вычислений (basic mechanism of object-oriented computation). Это обращение к компоненту или вызов компонента (feature call). В процессе выполнения кода ОО-системы все вычисления реализуются путем вызова соответствующих компонентов определенных объектов.

Приведенный конкретный пример означает вызов компонента translate класса POINT применительно к объекту p1 с аргументами 4.0 и -1.5, соответствующими a и b в объявлении translate в указанном классе. В общем случае допустимы две основные формы записи вызова компонента.

x.f

x.f (u, v, ...)

Здесь x называется целью (target) вызова и может быть сущностью или выражением, которые во время выполнения присоединены к конкретному объекту. Цель x, как любая сущность или выражение, имеет определенный тип, заданный классом C, следовательно, f должен быть одним из компонентов класса C. Точнее говоря, в первом случае f должен быть атрибутом или подпрограммой без аргументов, а во втором - подпрограммой с аргументами. Значения u, v, ... называются фактическими аргументами (actual arguments) вызова и они должны быть выражениями, число и тип которых должны в точности соответствовать числу и типу формальных аргументов (formal arguments) объявленных для f в классе C.

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

Результат рассмотренного выше вызова во время выполнения определяется следующим образом:

Эффект вызова компонента f для цели x

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

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

translate (p1, 4.0, -1.5)

В отличие от ОО-стиля в данном вызове все аргументы равноправны. Объектно-ориентированная форма не столь симметрична, определенный объект (в данном случае точка p1) выбирается в качестве цели, другим аргументам (действительные числа 4.0 и -1.5) отводится вспомогательная роль. Выбор единственного объекта в качестве цели для каждого вызова занимает центральное место в ОО-методе вычислений.

Принцип единственности цели

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

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

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

Как функционирует слияние модуль-тип

Функциональные возможности класса POINT, рассматриваемого как модуль, в точности соответствуют операциям доступным для экземпляров класса POINT, рассматриваемого как тип

Эта идентификация операций экземпляров типа и служб (services), предоставляемых модулем, лежит в основе структурной дисциплины, навязываемой ОО-методом.

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

Сама форма вызова показывает, почему текст подпрограммы (translate в классе POINT) не нуждается в дополнительной идентификации объекта Current. Поскольку любой вызов подпрограммы связан с определенной целью, которая явно обозначена при вызове, то при выполнении вызова имя каждого компонента в тексте подпрограммы (например, x в тексте translate) будет присоединено к той же цели. Таким образом, при выполнении вызова

p1.translate (4.0, -1.5)

каждое вхождение x в тело translate, как в следующей инструкции

x := x + a

означает: "x объекта p1".

Из этих соображений следует точный смысл понятия Current, как цели текущего вызова. Так в течение всего времени выполнения приведенного выше вызова Current будет обозначать объект, присоединенный к p1. При другом вызове Current будет обозначать цель нового вызова. Можно сформулировать следующий принцип вызова компонет (Feature Call principle):

Принцип вызова компонента

[x]. (F1) Любой элемент программы может выполняться только как часть вызова подпрограммы.

[x]. (F2) Каждый вызов имеет цель.

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

x.f

x.f (u, v, ...)

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

Однако другие вызовы могут быть неквалифицированны, поскольку их цель не указана. В качестве примера предположим, что необходимо в класс POINT добавить процедуру transform, которая будет комбинацией процедур translate и scale точки. Текст такой процедуры может обращаться к процедурам translate и scale:

transform (a, b, factor: REAL) is

-- Сместиться на a по горизонтали, на b по вертикали,

-- затем изменить расстояние до начала координат в factor раз.

do

translate (a, b)

scale (factor)

end

Тело процедуры содержит вызовы translate и scale. В отличие от предыдущих примеров здесь не указана точная цель и не применяется точечная нотация. Такие вызовы называют неквалифицированными (unqualified).

Неквалифицированные вызовы не нарушают пункта F2 принципа вызова компонент, так как тоже имеют цель. В данном случае целью является текущий экземпляр. Когда процедура transform вызывается по отношению к определенной цели, вызовы translate и scale имеют ту же цель. Фактически приведенный выше код эквивалентен следующему

do

Current.translate (a, b)

Current.scale (factor)

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

Приведенные неквалифицированные вызовы являются вызовами процедур. Аналогичные соображения можно распространить и на атрибуты, хотя наличие вызовов в этом случае возможно менее очевидно. Ранее было отмечено, что в теле процедуры translate присутствие x в выражении x + a означает поле x текущего экземпляра. Можно истолковать это иначе - как вызов компонента x и выражение в полной форме примет вид Current.x+a.

В общем случае любые инструкции или выражения вида:

f

или:

f (u, v, ...)

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

Current.f

Current.f (u, v, ...)

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

Рассмотрение выражения:

x + a

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

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

Для лучшего понимания необходимо обсудить определение типа REAL. Сформулированное ранее объектное правило (лекция 7) подразумевает, что каждый тип основан на каком-то классе. Это в равной мере относится к предопределенным классам, аналогичным REAL, и к классам, определенным разработчиком, таким как POINT. Предположим, что необходимо описать REAL как класс. Нетрудно определить набор существенных компонентов: арифметические операции (сложение, вычитание, изменение знака...), операции сравнения (меньше чем, больше чем...). Итак, первый набросок будет выглядеть так:

indexing

description: "Действительные числа (не окончательная версия!)"

class REAL feature

plus (other: REAL): REAL is

-- Сумма текущего значения и other

do

...

end

minus (other: REAL) REAL is

-- Разность между текущим значением и other

do

...

end

negated: REAL is

-- Текущее значение, взятое с противоположным знаком

do

...

end

less_than (other: REAL): BOOLEAN is

-- Текущее значение меньше чем other?

do

...

end

... Другие компоненты ...

end

При использовании такого описания класса уже нельзя более записывать арифметическое выражение в виде: x + a. Вместо этого надо использовать следующий вызов:

x.plus (a)

По аналогии, вместо привычного -x следует теперь писать x.negated.

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

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

x + a

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

indexing

description: "Real numbers"

class REAL feature

infix "+" (other: REAL): REAL is

-- Сумма текущего значения и other

do

...

end

infix "-" (other: REAL) REAL is

-- Разность между текущим значением и other

do

...

end

prefix "-": REAL is

-- Текущее значение, взятое с противоположным знаком

do

...

end

infix "<" (other: REAL): BOOLEAN is

-- Текущее значение меньше чем other?

do

...

end

... Other features ...

end

Введены два новых ключевых слова - infix и prefix. Единственное синтаксическое новшество заключается в том, что имена компонент не являются идентификаторами (такими как distance или plus), а записываются в одной из двух форм (В следующей лекции будет показано, как определить "развернутый класс". См. "Роль развернутых типов".)

infix "§"

prefix "§"

где § заменяется конкретным знаком операции (+, -, *, <, <= и др.). Компонент может иметь имя в инфиксной форме только если является функцией с одним аргументом, примерами могут служить plus, minus и less_than в первоначальной версии класса REAL. Префиксная форма может использоваться только для функций без аргументов или атрибутов.

Инфиксные и префиксные компоненты, называемые далее компоненты-операции (operator features), используются аналогично именованным компонентам (identifier features). Существуют лишь два синтаксических различия. Для имен компонентов-операций при их объявлении используются формы infix "§" или prefix "§", а не идентификаторы. Вызов компонентов-операций в случае инфиксных компонент имеет вид:

u § v

для префиксных:

§ u

Компоненты-операции поддерживают только квалифицированные вызовы. Неквалифицированный вызов plus (y) в подпрограмме первой версии класса REAL во второй версии должен быть записан в виде Current + y. Для именованных компонентов аналогичная нотация Current.plus (y) допустима, но обычно не используется.

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

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

+ - a / < > = \ ^ @ # | &

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

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

not and or xor and then or else implies

Базовые классы (INTEGER и другие) используют так называемые стандартные операции:

[x]. префиксные: + - not

[x]. инфиксные: + - a / < > <= >= = // \\ ^ and or xor and then or else implies .

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

[x]. Далее в классе ARRAY будет использован инфиксный компонент-операция "@" для функции, возвращающей указанный элемент массива. Обращение к i-ому элементу массива будет выглядеть как a @ i.

[x]. В класс POINT вместо функции distance можно ввести компонент-операцию "|-|" и расстояние между точками p1 and p2 будет записываться в виде p1 |-| p2, а не как p1.distance(p2).

Все операции имеют фиксированный приоритет, стандартные операции имеют свой обычный приоритет, а все свободные операции обладают более высоким приоритетом.

Использование компонентов-операций позволяет использовать общепринятую нотацию для выражений и одновременно отвечает требованиям полной унификации системы типов. Реализация арифметических и булевых операций как компонентов класса INTEGER вовсе не должна быть причиной снижения производительности. Концептуально a + x является вызовом компонента, но хороший компилятор может создать в результате обработки такого вызова код не менее эффективный, чем компиляторы C, Pascal, Ada или других языков, в которых "+" это жестко зафиксированная языковая конструкция.

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

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

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

По умолчанию все компоненты доступны для всех клиентов. Для класса

class S1 feature

f ...

g ...

...

end

компоненты f, g, ... доступны всем клиентам S1. Это означает, что если в классе C объявлена сущность x класса S1, то вызов

x.f ...

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

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

class S2 feature

f ...

g ...

feature {A, B}

h ...

...

end

Компоненты f и g по-прежнему доступны всем клиентам. Компонент h доступен только для классов A и B, а также их потомков (прямых или косвенных). Это означает, что для некоторого x типа S2 следующий вызов

x.h

является допустимым только в исходных текстах классов A, B или одного из их потомков.

В особом случае, когда необходимо скрыть компонент i от всех клиентов, можно объявить его экспортируемым пустому списку клиентов (Не рекомендуемый стиль (см. ниже S5).):

class S3 feature { }

i ...

end

В этом случае любой вызов x.i(...) недопустим. Единственная возможность обращения к i - неквалифицированный вызов

i (...)

в тексте подпрограммы класса S3 или его потомков. Такой механизм обеспечивает полное скрытие информации.

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

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

Использованный выше стиль объявления скрытой компоненты i не слишком удачен. Это хорошо видно в следующем примере (Не рекомендуемый стиль (см. ниже S5).)

class S4 feature

exported ...

feature {}

secret ...

end

где secret является скрытой компонентой, а exported - общедоступной. Разница в написании feature {} с пустым списком в скобках и feature без всяких скобок едва заметна. Гораздо разумнее вместо пустого использовать список, содержащий единственный класс NONE (Рекомендуемый стиль.)

class S5 feature

... exported ...

feature {NONE}

... secret ...

end

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

Рассмотрим объявление класса

indexing

замечание: "Ошибочное объявление (объяснение см. ниже)"

class S6 feature

x: S6

my_routine is do ... print (x.secret) ... end

feature {NONE}

secret: INTEGER

end -- class S6

Наличие в объявлении класса атрибута x типа S6 и вызова x.secret делает его собственным клиентом. Но такой вызов недопустим, так как компонент secret скрыт от всех клиентов! Тот факт, что неавторизованным клиентом является сам класс S6, нечего не меняет - объявленный статус secret делает недопустимым любой вызов вида x.secret. Всякие исключения нарушают простоту сформулированного правила.

Есть простое решение: написать вместо feature {NONE} предложение feature {S6} , экспортируя компоненту самому себе и своим потомкам.

Необходимо отметить, что подобный прием необходим, только если в тексте класса присутствует квалифицированный вызов аналогичный print (x.secret). Очевидно, что неквалифицированный вызов secret в инструкции print (secret) допустим без дополнительных ухищрений. Все компоненты, объявленные в данном классе, могут использоваться в подпрограммах данного класса и его потомков. Только при наличии квалифицированных вызовов приходится экспортировать компонент самому себе.

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

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

p1.translate (u, v)

Однако возникает следующий вопрос: что в действительности обозначает p1? Ответ опять относителен. Предположим, приведенный вызов присутствует в тексте некоторого класса GRAPHICS, а p1 это атрибут GRAPHICS. Тогда очевидно, что в этом случае p1 фактически означает Current.p1. Но это не ответ на поставленный вопрос, так как неизвестно, что представляет собой объект Current в момент вызова! Другими словами, теперь необходимо установить клиента, вызывающего подпрограмму класса GRAPHICS, в которой используется наш вызов.

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

[x]. (F1) Любой элемент программы может выполняться только как часть вызова подпрограммы.

[x]. (F2) Каждый вызов имеет цель.

Любой вызов может принимать одну из следующих форм:

[x]. неквалифицированная: f (a, b, ...);

[x]. квалифицированная: x.g (u, v, ...) .

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

[x]. (T1) Для неквалифицированного вызова t это просто OBJ.

[x]. (T2) Если x это атрибут, то x - поле объекта OBJ-имеет значение, которое, в свою очередь, присоединено к некоторому объекту - он и есть t.

[x]. (T3) Если x - функция, то необходимо сначала осуществить ее вызов (неквалифицированный), результат которого и дает t.

[x]. (T4) Если x - локальная сущность r, то к моменту вызова предыдущие инструкции вычислят значение x, присоединенное к определенному объекту, который и является объектом t.

Проблема в том, что все четыре ответа опять относительны и могут помочь только в том случае, если известно, чем является текущий экземпляр OBJ. Очевидно, что OBJ это цель текущего вызова! Ситуация как в песенке о том, как у попа была собака (в оригинале: котенок съел козленка, котенка укусил щенок, щенка ударила палка ...) - бесконечная цепь.

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

Определение: выполнение системы

Выполнение ОО-программной системы состоит из следующих двух шагов:

[x]. Создание определенного объекта, называемого корневым объектом выполнения.

[x]. Применение определенной процедуры, называемой процедурой создания, к данному объекту.

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

Зная, где все началось, несложно проследить судьбу Current в процессе этой цепной реакции. Первым текущим объектом, созданным в момент Большого Взрыва, является корневой объект. Рассмотрим далее некоторый этап выполнения системы. Пусть r-последняя вызванная подпрограмма, а текущим на момент вызова r был объект OBJ. Тогда во время выполнения r объект Current определяется следующим образом:

[x]. (C1) Если в r выполняется инструкция, не являющаяся вызовом подпрограммы (например, присваивание), то текущим остается прежний объект.

[x]. (C2) Неквалифицированный вызов также оставляет тот же объект текущим.

[x]. (C3) Запуск квалифицированного вызова x.f ... делает текущим объект, присоединенный к x. Зная объект OBJ, можно идентифицировать x, используя сформулированные ранее правила T1-T4. После завершения вызова роль текущего возвращается к объекту OBJ.

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

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

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

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

[x]. Создать совокупность классов CS, называемую множеством классов (class set) системы.

[x]. Указать класс из CS, являющийся корневым (root class).

[x]. Указать в корневом классе процедуру, играющую роль корневой процедуры создания (root creation procedure) .

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

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

[x]. Класс D непосредственно необходим классу C , если текст C ссылается на D. Здесь можно выделить два варианта: C может быть либо клиентом D, либо потомком D.

[x]. Класс E необходим классу C, либо, когда C совпадает с E, либо существует класс D непосредственно необходимый классу С, и классу D необходим (возможно, рекурсивно) класс E. Другими словами, существует цепочка классов, связанных отношением непосредственной необходимости, и началом этой цепочки является класс C, а концом - класс E.

Теперь можно дать определение замкнутой системы.

Определение: замкнутая система

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

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

Этот процесс называется компоновкой или сборкой (assembly) системы и является завершающим этапом разработки.

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

Не совсем. В традиционном понятии основной программы объединены две не связанные концепции:

[x]. Место, с которого начинается выполнение.

[x]. Вершина или фундаментальный компонент архитектуры системы.

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

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

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

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

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

Как практически реализовать процесс компоновки системы?

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

[x]. (A1) Имя корневого класса.

[x]. (A2) Генеральная совокупность (universe) файлов, содержащих тексты классов, необходимых корневому.

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

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

Рассмотрим типичный документ Lace, так называемый файл Ace:

system painting root

GRAPHICS ("painting_application")

cluster

base_library: "\ library\ base";

graphical_library: "\ library\ graphics";

painting_application: "\ user\ application"

end -- system painting

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

Операционные системы, такие как Windows, VMS или Unix, содержат удобный механизм поддержки кластеров - подкаталоги. Их файловые системы имеют древовидную структуру. Конечные узлы дерева (листья), называемые "обычными файлами", содержат непосредственно информацию, а промежуточные узлы, подкаталоги, содержат наборы файлов, состоящие из обычных файлов и подкаталогов.

Рис. 7.7.  Структура каталогов

Можно ассоциировать каждый кластер с подкаталогом. В Lace используется следующее соглашение: каждый кластер, например base_library, имеет связанный с ним подкаталог, имя которого дано в двойных апострофах - "\ library\ base". Такое соглашение об именах файлов используется в Windows (\dir1\dir2\ ... ) и здесь приведено только ради примера. Соответствующие имена Unix получаются заменой символов обратной косой черты на обычную.

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

Предложение root Lace служит для задания корневого класса системы. В данном случае корневым является класс GRAPHICS и он находится в кластере painting_application. Если только один класс в генеральной совокупности называется GRAPHICS, то нет необходимости указывать кластер.

Предположим, что компилятор начинает создание системы, описанной в приведенном файле Ace. Далее предположим, что ни один из файлов системы еще не откомпилирован. Компилятор находит текст корневого класса GRAPHICS в файле graphics.e кластера painting_application, который размещается в каталоге \user\application. Анализируя текст класса GRAPHICS, компилятор находит имена классов, которые необходимы GRAPHICS и ведет поиск файлов с соответствующими именами в каталогах трех кластеров. Далее этот поиск повторяется до тех пор, пока не будут обнаружены все классы, прямо или косвенно необходимые корневому классу GRAPHICS.

Важнейшей особенностью этого процесса является возможность его автоматизации. Разработчику ПО не нужно составлять списки зависимых модулей, известных как "Make-файлы", или указывать в каждом файле имена файлов, необходимых для его компиляции ("директивы Include" в C и C++). Кроме своей утомительности процесс создания этой информации вручную является потенциальным источником ошибок. Единственное, что самостоятельно не сможет определить ни одна утилита - это имя корневого класса и размещение необходимых классов в файловой системе.

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

Конечным продуктом процесса компиляции является исполняемый файл, имя которого совпадает с именем системы в файле Ace, в данном примере - painting.

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

Использование независимого от языка разработки языка описания системы аналогичного Lace позволяют классам оставаться системно независимыми. Классы являются компонентами ПО, аналогичными электронным микросхемам, и система собрана из конкретного набора классов подобно компьютеру, собранному из определенного набора микросхем.

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

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

class SIMPLE creation

make

feature

make is

-- Вывод строки.

do

print_line ("Hello Sarah!")

end

end

Процедура print_line с параметром некоторого типа выводит значение соответствующего объекта, в данном случае строки. Другая процедура с именем print делает то же самое, но без перехода на новую строку. Обе процедуры доступны во всех классах и унаследованы от универсального предка GENERAL, обсуждаемого далее. (О классе GENERAL см. "Универсальные классы", лекция 16)

Для получения системы, которая будет выводить данную строку необходимо сделать следующее:

[x]. (E1) Поместить текст класса в файл simple.e.

[x]. (E2) Запустить компилятор.

[x]. (E3) Если файл Ace заранее не создан, то можно запросить автоматическое создание шаблона и в режиме его редактирования заполнить имя корневого класса - SIMPLE, системы - my_first и указать каталог кластера.

[x]. (E4) После выхода из редактора компилятор осуществит компоновку системы и создаст исполняемый файл my_first.

[x]. (E5) Выполнить my_first. В режиме командной строки необходимо просто ввести my_first. В системах с графическим интерфейсом появится новая пиктограмма с именем my_first и запуск программы производится двойным щелчком на ней.

В результате на консоли появится сообщение:

Hello Sarah!

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

[A]

x.g (u, v, ...)

присутствующую в тексте подпрограммы r класса C и предположим, что x это атрибут. Как и когда она будет выполняться? Класс C должен быть включен в систему, скомпонованную затем с помощью соответствующего файла Ace. Далее следует запустить выполнение системы, которое начнется с создания экземпляра корневого класса. Корневая процедура создания должна выполнить одну или более операций, которые прямо или косвенно создадут объект C_OBJ - экземпляр класса C, а затем выполнят вызов:

[B]

a.r (...)

где a присоединено к C_OBJ. Далее вызов [A] выполнит g с заданными аргументами, используя в качестве цели объект, присоединенный к полю x объекта C_OBJ.

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

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

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

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

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

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

f ...

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

g (a1: A; b1: B; ...) ...

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

f: T ...

g (a1: A; b1: B; ...): T ...

В первом примере все еще есть выбор - f может быть либо атрибутом, либо функцией без аргументов. Во втором случае неопределенность заканчивается и g может быть только функцией. Для f неопределенность разрешается в зависимости от того, что следует за T. Если ничего, то f это атрибут, как в следующем примере:

my_file: FILE

Но если далее присутствует ключевое слово is, а за ним тело подпрограммы (do или варианты once и external, рассматриваемые позже), как в примере:

f: T is

-- ...

do ... end

то f - функция. Еще один вариант

f: T is some_value

определяет f как атрибут-константу (constant attribute), значение которой равно some_value. (Атрибуты-константы обсуждаются в лекции 18)

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

Рассмотрим подробнее следствия принципа унифицированного доступа и объединения атрибутов и подпрограмм под общим заголовком - компоненты. (См."Унифицированный доступ", лекция 3. См. также данную лекцию.)

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

Рассмотрим класс PERSON, содержащий компонент типа INTEGER без параметров. Если автор клиентского класса записывает выражение

Isabelle.age

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

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

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

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

[x]. Первое следствие касается программной документации. Стандартная документация класса для клиента, известная как краткая форма класса, составляется так, чтобы отсутствовала разница в описаниях атрибутов и функций без параметров. (См. "Использование утверждений в документации: краткая форма класса", лекция 11)

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

В завершение предшествующей дискуссии необходимо обсудить вопрос об экспорте атрибутов. Рассмотренный в этой лекции класс POINT имеет атрибуты x и y и экспортирует их клиентам, также как и функции rho и theta. Для получения значения атрибута некоторого объекта используется обычная нотация для вызова компонентов в виде my_point.x или my_point.theta.

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

Следуя подходу Smalltalk, доступ к атрибуту можно обеспечить только с помощью небольшой экспортированной функции, возвращающей значение атрибута. В примере класса POINT назовем атрибуты internal_x, internal_y и добавим функции abscissa и ordinate. Лаконичный синтаксис Smalltalk допускает присваивание одинаковых имен атрибуту и функции, избавляя от необходимости придумывать специальные имена для атрибутов.

class POINT feature

-- Общедоступные компоненты:

abscissa: REAL is

-- Горизонтальная координата

do Result := internal_x end

ordinate: REAL is

-- Вертикальная координата

do Result := internal_y end

... Другие компоненты аналогичны предыдущей версии ...

feature {NONE}

-- Компоненты недоступные клиентам:

internal_x, internal_y: REAL

end

Этот подход имеет два недостатка:

[x]. Он побуждает авторов классов писать много маленьких функций, аналогичных abscissa и ordinate. Несмотря на то, что такие функции будут очень короткими, автор класса будет тратить на их написание дополнительные усилия, а их присутствие затрудняет восприятие исходного текста.

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

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

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

Экспорт атрибута с использованием рассмотренной техники делает его доступным клиентам только для чтения в виде my_point.x. Модификация атрибута путем присваивания не разрешается. Следующая синтаксическая конструкция недопустима для атрибутов (Внимание: недопустимая конструкция - только для иллюстрации.):

my_point.x := 3.7

Действует простое правило. Если attrib является атрибутом, то a.attrib является выражением, а не сущностью. Следовательно, ему нельзя присвоить значение, как нельзя присвоить значение выражению a + b.

Возможность модификации attrib достигается добавлением экспортируемой процедуры вида:

set_attrib (v: G) is

-- Установка значения attrib равным v.

do

attrib := v

end

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

class C feature [AM]

...

feature [A]{D, E}

...

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

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

class COUNTING feature

counter: INTEGER

increment is

-- Увеличение значения счетчика

do

counter := counter + 1

end

decrement is

-- Уменьшение значения счетчика

do

counter := counter - 1

end

end

Аналогичным образом клиенты класса POINT не имеют возможности непосредственно изменять координаты точки x и y. Для этой цели служат экспортированные процедуры translate и scale.

При изучении утверждений мы рассмотрим еще одну принципиальную причину недопустимости непосредственных присваиваний a.attrib := some_value. Причина в том что не любые значения some_value могут быть допустимыми. Можно определить процедуру

set_polygon_size (new_size: INTEGER) is

-- Установить новое значение числа вершин многоугольника

require

new_size >= 3

do

size := new_size

end

параметр которой может равен 3 или больше. Прямое присваивание не позволяет учесть это условие и в результате получается некорректный объект.

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

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

Уровень 0 соответствует полному отсутствию доступа к атрибуту. На уровне 1 открыт доступ только для чтения. На уровне 2 разрешена модификация с помощью специальных алгоритмов. На уровне 3 новое значение может быть присвоено, только если удовлетворяет определенным условиям, как в примере для многоугольника. На уровне 4 ограничения снимаются.

Решение, описанное в данной лекции, следует из приведенного анализа. Экспорт атрибута дает клиентам право доступа только для чтения (уровень 1). Разрешение на модификацию обеспечивается написанием и экспортом соответствующих процедур. Они предоставляют ограниченные права, как в примере для счетчика (уровень 2), право модификации при соблюдении определенных условий (3) и неограниченный доступ (4).

Это решение является развитием идей, существующих в различных ОО-языках:

[x]. В Smalltalk для обеспечения доступа клиентов к атрибуту на уровне 1 приходится писать специальные функции подобные abscissa and ordinate. Это источник дополнительной работы для программиста и причина снижения производительности.

[x]. C++ и Java представляют другую крайность. Если атрибут экспортирован, то он сразу становится доступным на уровне 4 для чтения и для записи путем прямого присваивания в стиле my_point.x := 3.7. Единственный путь реализации других уровней это полное скрытие атрибута и написание экспортированных процедур для поддержки уровней 2 и 4 и функций для уровня 1. Далее все аналогично Smalltalk. Поддержка уровня 3 невозможна в связи с отсутствием в этих языках механизма утверждений.

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

На уровнях 2 и 3 неизбежно использование явных вызовов процедуры подобных my_polygon.set_size (5) для изменения значения атрибута. Существует опасение, что использование такого стиля на уровне 4 негативно скажется на производительности. Тем не менее компилятор может создавать для вызова my_point.set_x (3.7) код столь же эффективный, как и для my_point.x := 3.7, если бы такое присваивание было бы разрешено.

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

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

[x]. Встраивание кода далеко не всегда применимо, и компилятор гораздо корректнее может принять правильное решение.

[x]. При внесении изменений в ПО, в частности с использованием наследования, встроенная подпрограмма может стать не встроенной. Компилятор выявит такие ситуации гораздо лучше, чем человек.

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

[x]. Программисты могут занять время более полезной работой.

Современная концепция разработки ПО подразумевает, что утомительную, автоматизируемую и тонкую работу по оптимизации нужно возлагать на соответствующие утилиты, а не на человека. Это обстоятельство является одной из причин принципиальной критики C++ и Ada. Мы вернемся к этому вопросу при обсуждении двух других ключевых моментов объектной технологии - управления памятью и динамического связывания. (См. "Требования к сборщику мусора", лекция 9, и "Подход C++ к связыванию", лекция 14)

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

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

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

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

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

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

В исходных текстах классов, в предложениях feature, перечислены компоненты, доступные другим классам. Почему бы, в свою очередь, не включать списки компонентов, полученных от других классов? Язык Modula-2 поддерживает, например, объявление import.

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

a.f

но тогда должно присутствовать объявление a:

a: C

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

Следовательно, нет необходимости в предложении import. ("Плоская краткая форма", лекция 11)

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

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

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

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

f: INTEGER is

do

if some_condition then Result := 10 end

end

возвратит 10 при выполнении условия some_condition на момент вызова и 0 (значение по умолчанию при инициализации INTEGER) в противном случае. Насколько известно автору, техника использования Result была впервые предложена в данной книге. С момента выхода первого издания она была включена по крайней мере в один язык - Borland Delphi. Надо заметить, что она неприемлема для языков, допускающих объявление функций внутри других функций, поскольку имя Result становится двусмысленным. В различных языках наиболее часто используются следующие приемы:

[x]. (A) Заключительные инструкции return (C, C++/Java, Ada, Modula-2).

[x]. (B) Использование имени функции в качестве переменной (Fortran, Algol 60, Simula, Algol 68, Pascal).

Соглашение A основано на инструкции вида return e , выполнением которой завершается функция, возвращая e в качестве результата. Преимущество этого метода в его ясности, поскольку возвращаемое значение четко выделено в тексте функции. Однако он имеет и отрицательные стороны:

[x]. (A1) На практике результат часто определяется в процессе вычислений, включающих инициализацию и ряд промежуточных изменений значения. Возникает необходимость во временной переменной для хранения промежуточных результатов.

[x]. (A2) Методика имеет тенденцию к использованию модулей с несколькими точками завершения. Это противоречит принципам хорошего структурирования программ.

[x]. (A3) В языке должна быть предусмотрена ситуация, когда последняя инструкция, выполненная при вызове функции, не является return. В программах Ada в этом случае возбуждается исключение времени выполнения.

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

function name (arguments): TYPE is

do

...

return

expression

end

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

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

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

f := x

а если f является частью выражения, то подразумевается рекурсивный вызов функции

x := f

который допустим только при отсутствии у f параметров. Однако присваивания вида

f := f + 1

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

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

do

if some_condition then Result := "Some specific value" end

end

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

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

prefix "|_": INTEGER is

-- Целая часть числа

do

... Реализация опущена ...

ensure

no_greater: Result <= Current

smallest_possible: Result + 1 > Current

end

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

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

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

Определение: сущность (entity)

Сущность может представлять собой:

[x]. (E1) Атрибут класса

[x]. (E2) Локальную сущность подпрограммы, включая предопределенную сущность Result для функции

[x]. (E3) Формальный аргумент подпрограммы

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

Все сущности, за исключением формальных аргументов (E3), доступны для записи, то есть могут присутствовать как цель x в присваивании x := some_value.

[x]. Фундаментальная концепция объектной технологии основана на понятии класса. Класс это абстрактный тип данных, частично или полностью реализованный.

[x]. Класс может иметь экземпляры, называемые объектами.

[x]. Нельзя путать объекты (динамические элементы) с классами (статическим описанием свойств, общих для множества объектов времени выполнения).

[x]. При последовательном подходе к объектной технологии каждый объект является экземпляром класса.

[x]. Класс одновременно служит модулем и типом. Оригинальность и мощь ОО-модели следует частично из интеграции этих понятий.

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

[x]. Базовым механизмом ОО-вычислений является вызов компонентов (обращение к компонентам) класса. Вызов компонента применяет компонент к экземпляру класса (возможно с аргументами).

[x]. При вызове именованных компонентов используется точечная нотация, а при вызове компонент-операций - инфиксная или префиксная нотация.

[x]. Каждая операция относительна к "текущему экземпляру" класса.

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

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

[x]. Системы имеют децентрализованную архитектуру. Порядок действий несущественен для разработки.

[x]. Уточнение процесса сборки достигается с помощью простого языка описания систем Lace. В спецификации Lace, называемой файлом Ace, указывается корневой класс и набор каталогов, в которых размещены кластеры системы.

[x]. Процесс компоновки может быть автоматизирован без использования Make-файлов и директив Include.

[x]. Механизм скрытия информации требует гибкости. Наряду с неограниченным доступом и полным скрытием может потребоваться экспорт только для части клиентов. Атрибуты могут быть доступны только для чтения, для чтения и ограниченной модификации и в режиме полного доступа.

[x]. Экспорт атрибута означает доступ к нему только для чтения. Модификация требует вызова соответствующей экспортированной процедуры.

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

[x]. Необходимость в надстройках над классами - супермодулей - отсутствует. Классы должны оставаться независимыми программными компонентами.

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

Понятие класса пришло из языка Simula 67 (см. библиографические ссылки к лекции 17 курса "Основы объектно-ориентированного проектирования"). Класс в Simula является одновременно модулем и типом, однако эта особенность специально не подчеркивалась и была утрачена у преемников Simula.

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

(g (x)) (y)= f (x, y)

Редуцировать функцию это, другими словами, специализировать ее по первому аргументу. Этот прием аналогичен использованной в данной лекции замене традиционной процедуры rotate, имеющей два параметра:

rotate (some_point, some_angle)

на функцию с одним параметром, имеющую цель:

some_point.rotate (some_angle)

В [M 1990] описана редукция и некоторые из ее применений в информатике, в частности, при формальном изучении синтаксиса и семантики языков программирования. Редукция будет еще рассматриваться при обсуждении графического интерфейса пользователя (лекция 14 курса "Основы объектно-ориентированного проектирования").

В отличие от положений данной лекции в некоторых языках объект рассматривается как языковая конструкция, а не как понятие времени выполнения. Такой подход предназначен для исследовательских целей и не нуждается в понятии класса. Наиболее известным представителем этой школы является язык Self [Chambers 1991], в котором вместо классов используются "прототипы".

Детали соглашения об инфиксных и префиксных операциях, в частности таблица приоритетов, приведены в [M 1992].

James McKim обратил мое внимание на последний аргумент в пользу соглашения Result (использование для постусловий).

Напишите спецификацию абстрактного типа данных для описания точки на плоскости.

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

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