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

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

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