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

• Название: Основы объектно-ориентированного программирования
• Автор: Бертран Мейер
• Жанр: Прочая околокомпьтерная литература

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

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

---

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], в котором вместо классов используются "прототипы".