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

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

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