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

-- Текущий баланс
do
Result := list_of_deposits.total - list_of_withdrawals.total
end
...
End

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

class ACCOUNT2 inherit
ACCOUNT1
redefine balance end
feature
balance: INTEGER
-- Текущий баланс
...
end

По-видимому, в классе ACCOUNT2 нужно будет переопределить некоторые процедуры, такие как withdraw и deposit, чтобы, кроме других своих обязанностей они еще модифицировали нужным образом balance, сохраняя в качестве инварианта свойство: balance = list_of_deposits.total - list_of_withdrawals.total.

В этом примере новое объявление является переопределением. Его результатом может также оказаться превращение отложенного компонента в атрибут. Например, пусть в отложенном классе LIST имеется компонент

count: INTEGER is
-- Число вставленных элементов
deferred
end

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

count: INTEGER

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

Переобъявление функции как атрибута, объединенное с полиморфизмом и динамическим связыванием, приводят к полной реализации принципа Унифицированного Доступа. Сейчас можно не только реализовать запрос клиента вида a.service либо через память, либо посредством вычисления, но один и тот же запрос в процессе одного вычисления может в одних случаях запустить доступ к некоторому полю, а в других - вызвать некоторую функцию. Это может, в частности, случиться при выполнении одного и того же вызова a.balance, если по ходу вычисления a будет полиморфно присоединяться к объектам разных классов.

Обратного пути нет

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

a := some_expression

Если потомок C переопределит a как функцию, то эта функция будет не применима, поскольку нельзя использовать функцию в левой части присваивания.

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

Использование исходной версии при переопределении

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

Например, класс BUTTON, наследник класса WINDOW, может переопределить компонент display, рисующий кнопку, так чтобы вначале рисовалось окно, а затем появлялась рамка:

class BUTTON inherit
WINDOW
redefine display end
feature -- Вывод
display is
-- Изобразить как кнопку.
do
'Изобразить как нормальное окно'; -- См. ниже