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

Две последние проблемы разрешаются, если рассматривать 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].Исполняемый ансамбль классов называется системой. Система содержит корневой класс и все классы, которые необходимы корневому прямо или косвенно через клиентские отношения или наследование. Выполнение системы сводится к созданию экземпляра корневого класса и вызову процедуры создания для данного экземпляра.