Инкапсуляция

в прямом обращении к их внутренним полям данных.

STRING;
FUNCTION GetDate : STRING;
FUNCTION GetRate : REAL;
PROCEDURE ShowName;
PROCEDURE ShowDate;
PROCEDURE ShowRate;

END;

REAL;
FUNCTION GetSum : REAL;
PROCEDURE ShowBall;
PROCEDURE ShowSum;
PROCEDURE ShowAll;
END;

косвенной работы с полями данных, например:
WITH Student DO
BEGIN

Init ('Петр Петров','25-06-1995', 40000,4.5);
ShowAll;
END;

помощью методов этого объекта.

вообще возможно, создавать гибкие процедуры, которые работали бы с формальными

параметрами переменных типов.
как это делает, к примеру процедура WriteLn, которая может выводить на экран или в файл данные типа STRING, REAL, INTEGER, BOOLEAN и родственные им.

определен порожденный тип, то методы порождающего типа наследуются, однако, при

желании они могут переопределяться.

же именем, что и наследуемый метод,
но с другим телом

и с другим множеством параметров.

Init(Nm,Dt:STRING; Rt,Bl:REAL);
FUNCTION GetBall : REAL;
FUNCTION GetSum : REAL;
PROCEDURE ShowSum;
PROCEDURE ShowBall;
PROCEDURE

ShowAll;
END;

Ранее нами был определен тип TStudent, являющийся потомком типа TPerson:

используются для определения объекта TPerson (фамилию, дату выплат, ставку)
Чем TStudent

отличается отTperson?
Для объекта TStudent требуется еще и поле среднего балла Ball.

поле Ball, его инициализация требует нового метода Init, который инициализирует

и средний балл, и наследованные поля.

Процедура Init наследуется от предка, но в данном случае ее необходимо переопределить:

Name, Date и Rate, проще использовать метод инициализации объекта TPerson.

— это идентификатор типа родительского объекта;
Метод

— идентификатор метода этого типа.

не является обязательным.
В общем случае TPerson.Init выполняет важную, но скрытую

инициализацию.

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

Кроме того, любое изменение в родительском Методе автоматически оказывает влияние на все порожденные.

т.к. расчет производится в каждом случае по разному.
Метод TStudent.GetSum

должен учитывать средний балл студента.
Метод TTeacher.GetSum должен учитывать количество лекционных часов, часовую ставку и премиальные выплаты.
Метод TStaff.GetSum должен учитывать только размер премиальных выплат.

PRIVATE
Name: STRING[30];
Date: STRING[10]
Rate:

REAL;
PUBLIC
PROCEDURE Init(Nm,Dt:STRING; Rt:REAL);
PROCEDURE ShowAll;
END;

TStudent = OBJECT(TPerson)
PRIVATE
Ball: REAL;
PUBLIC
PROCEDURE Init(Nm,Dt:STRING; Rt,Bl:REAL);
FUNCTION GetSum : REAL;
PROCEDURE ShowSum;
PROCEDURE ShowAll;
END;







TStaff = OBJECT(TPerson)
PRIVATE
Bonus : REAL;
PUBLIC
PROCEDURE Init(Nm,Dt:STRING; Rt,Bn:REAL);
FUNCTION GetSum : REAL;
PROCEDURE ShowSum;
PROCEDURE ShowAll;
END;

Tteacher = OBJECT(TStaff)
PRIVATE
Hours :WORD;
HourRate:REAL;
PUBLIC
PROCEDURE Init (Nm,Dt:STRING; Rt,Bn,Hrt:REAL; Hr:WORD);
FUNCTION GetSum : REAL;
PROCEDURE ShowSum;
PROCEDURE ShowAll;
END;

IMPLEMENTATION

: REAL;
BEGIN
GetSum := Rate*Ball;
END;
В методе TStaff.GetSum

к ставке прибавляется размер премиальных выплат :

FUNCTION TStaff.GetSum : REAL;
BEGIN
GetSum := Rate+Bonus;
END;

Метод TTeacher.GetSum вызывает TStaff.GetSum и добавляет к этому значению размер часовой ставки, умноженный на количество часов :

FUNCTION TTeacher.GetSum : REAL;
BEGIN
GetSum:= TStaff.GetSum+Hours*HourRate;
END;

данных переопределяться не могут.

После того как поле данных в

иерархии объекта определено, никакой дочерний тип не может определить поле данных с таким же именем.

TPerson, TStudent, TStaff и TTeacher, являются статическими методами.
С ними связана

проблема наследования.

имеет вид:

PROCEDURE TStaff.ShowSum;
BEGIN
WriteLn(GetSum);
END;
Как ни странно, для объекта типа

ТТеасher эта процедура имеет тот же самый вид:
PROCEDURE TTeacher.ShowSum;
BEGIN
WriteLn(GetSum);
END;

дополнительные действия?
По сравнению с типом TStaff не изменилось ничего, кроме

копирования процедуры и подстановки квалификатора ТТеасher перед идентификатором ShowSum.
Возникает резонный вопрос, нет ли здесь логической ошибки?
Поскольку методы одинаковы, нет нужды помещать ShowSum в TStaff и TTeacher.
TTeacher автоматически наследует ShowSum от TStaff, поэтому нет необходимости переопределять этот метод.

Именно здесь и возникает проблема, связанная со статическими методами

будет помещена в область действия TTeacher для подавления метода ShowSum

объекта TStaff, метод не будет работать правильно, если он будет вызываться из объекта типа TTeacher.

Если TTeacher запускает метод ShowSum объекта TStaff, то и функция GetSum, используемая в методе, будет принадлежать объекту TStaff, и зарплата будет рассчитана неправильно, без учета количества часов.

и при вызове любой процедуры, компилятор замещает ссылки на TStaff.GetSum

и TStaff.ShowSum в исходном коде на их адреса в сегменте кода.
Поскольку тип TTeacher является потомком типа TStaff, то сначала в сегмент кода будет скомпилирована функция TStaff.GetSum.
Затем будет скомпилирована процедура TStaff.ShowSum, вызывающая TStaff.GetSum

TStaff.GetSum, что и составляет проблему.
Фактически, наследуется следующая процедура:
PROCEDURE TStaff.ShowSum;

BEGIN
WriteLn(GetSum);
END;

Метод объекта TStaff ничего не знает о существовании объекта TTeacher.

Вместо этого он должен быть переопределен своей второй копией, вызывающей уже правильный метод.

Таким образом, метод ShowSum нельзя наследовать.

необходимо помнить, что вызываемый метод является в точности таким, каким

он был определен и скомпилирован для родительского типа.

Если родительский метод вызывает другие методы, то вызываемые методы будут также родительскими методами, даже если дочерний объект содержит методы, которые переопределяют родительские.

смысле, в каком статической является статическая переменная: компилятор размещает ее

и определяет все ссылки на нее во время компиляции.

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

Выход заключается в том, что метод должен быть динамическим, а ссылки на него должны определяться во время выполнения.

Чтобы это стало возможным, Турбо Паскаль предоставляет механизмы поддержки так называемых виртуальных методов.

обобщения, называемый полиморфизмом.
Полиморфизм является способом присвоения действию имени, которое

используется всеми объектами иерархии, причем каждый объект иерархии использует это действие определенным образом.

хорошим примером полиморфизма в действии, предоставляемого с помощью виртуальных методов.
Каждый

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

Особым для каждого типа объекта является способ отображения самого себя на экране.

Можно отобразить на экране любой тип фигуры, но механизм рисования каждой является сугубо индивидуальным.
Одно слово "отобразить" используется для вывода многих фигур.
То же самое в примере с платежной ведомостью — функция GetSum вычисляет размер выплат для различных типов лиц.

Это и есть полиморфизм, а виртуальные методы реализуют его в Турбо Паскале.

метода
в случае статического метода компилятору заранее известна связь объекта

с методом, и он устанавливает ее на этапе компиляции.
в случае динамического метода компилятор как бы откладывает решение до момента выполнения программы.

связываются компилятором во время компиляции в один метод, называется
ранним

связыванием.

связываются при первой же возможности
т.е. во время компиляции
При позднем связывании

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

когда вызов действительно произойдет