При объявлении методов следует придерживаться следующих правил:

Например, очевидно, что метод, называющийся SaveToFile сохранит некоторую информацию в файл, а метод – LoadFromFile – загрузит ее.

Это же правило относится и к именам передаваемых методу параметров.

Например, параметр, называющийся FileName явно предназначен для передачи имени файла.

По степени видимости методы могут быть размещены с любой секции от private до public.

С наименованием методов все ясно. Разберемся теперь собственно с их реализацией.

unit Unit6;

interface
type

  TFirstClass=class
  private
    procedure PrivatMethod;
  end;

implementation

end.

Теперь необходимо его реализовать. Для этого в разделе implementation необходимо поместить требуемый код.

procedure TFirstClass.PrivatMethod;
begin
  // Код метода
end;

unit Unit6;

interface
type

  TFirstClass=class
  private
    procedure PrivatMethod; // Для реализации нажать <Ctrl>+<Shift>+<C>
  end;

implementation

{ TFirstClass }

procedure TFirstClass.PrivatMethod;
begin

end;

end.

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

Код метода имеет доступ ко всем (в том числе и private) атрибутам класса. Если же необходимо явно указать, что атрибут относится к данному классу, то можно использовать неявную ссылку Self.

Реализация методов имеет свои особенности по сравнению с простыми функциями и процедурами. Поскольку в соответствии с принципом полиморфизма названия методов класса-наследника могут совпадать с именами методов класса-предка, то должна быть возможность в методах наследника вызвать методы предка. Такая возможность реализуется с помощью ключевого слова inherited с указанием имени метода предка. Если метод предка вызывается из одноименного метода наследника, то имя метода можно не указывать, а ограничиться одним лишь словом inherited.

program Project6;
{$APPTYPE CONSOLE}
uses
  SysUtils;
type
  TFirst=class
    procedure StaticProc;
    procedure VirtualProc; virtual;
    procedure DynamicProc; dynamic;
    procedure Broken; virtual;
  end;
   TSecond=class(TFirst)
    procedure StaticProc;
    procedure VirtualProc; override;
    procedure DynamicProc; override;
    procedure Broken; virtual;
   end;

{ TFirst }

procedure TFirst.Broken;
begin
  Writeln('TFirst.Broken');
end;

procedure TFirst.DynamicProc;
begin
  Writeln('TFirst.DynamicProc');
end;

procedure TFirst.StaticProc;
begin
  Writeln('TFirst.StaticProc');
end;

procedure TFirst.VirtualProc;
begin
 Writeln('TFirst.VirtualProc');
end;

{ TSecond }

procedure TSecond.Broken;
begin
  inherited;
  Writeln('TSecond.Broken');
end;

procedure TSecond.DynamicProc;
begin
  inherited;
  Writeln('TSecond.DynamicProc');
end;

procedure TSecond.StaticProc;
begin
 inherited;
  Writeln('TSecond.StaticProc');
end;

procedure TSecond.VirtualProc;
begin
  inherited;
  Writeln('TSecond.VirtualProc');
end;

procedure TestClass(P: TFirst);
begin
  with P do
    begin
    StaticProc;
    VirtualProc;
    DynamicProc;
    Broken;
    end;
end;

var TestObj: TSecond;
begin
  TestObj:= TSecond.Create;
  Writeln('============ Test methods ============');
  with TestObj do
    begin
    StaticProc;
    VirtualProc;
    DynamicProc;
    Broken;
    end;
  Writeln('============ TestClass ============');
  TestClass(TestObj);
  Writeln('============ Test as ============');
    with TFirst(TestObj) do
    begin
    StaticProc;
    VirtualProc;
    DynamicProc;
    Broken;
    end;
  Readln;
end.

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

Второй класс TSecond является наследником TFirst и переопределяет все его методы. Причем виртуальный методы VirtualProc и динамический метод DynamicProc переопределяются (override), статический метод StaticProc и виртуальный метод Broken практически объявляется повторно.

Реализация всех методов класса TSecond обеспечивает вызов одноименных методов предка (TFirst) и использованием ключевого слова inherited.

Программа создает экземпляр класса TSecond и вызывает все его методы. В приведенном ниже листинге показан результат работы методов, обозначенный заголовком "Test methods".

============ Test methods ============
TFirst.StaticProc
TSecond.StaticProc
TFirst.VirtualProc
TSecond.VirtualProc
TFirst.DynamicProc
TSecond.DynamicProc
TFirst.Broken
TSecond.Broken
============ TestClass ============
TFirst.StaticProc
TFirst.VirtualProc
TSecond.VirtualProc
TFirst.DynamicProc
TSecond.DynamicProc
TFirst.Broken
============ Test as ============
TFirst.StaticProc
TFirst.VirtualProc
TSecond.VirtualProc
TFirst.DynamicProc
TSecond.DynamicProc
TFirst.Broken

Из листинга видно, что действительно при вызове методов потомка сначала вызываются методы предка (TFirst)

Вроде бы все работает как надо. Но что будет, если в программе понадобиться (а в программировании такая необходимость возникает весьма часто) централизованно обрабатывать экземпляры различных классов?

Для имитации такой обработки в программе реализована процедура TestClass, которая принимает параметр типа TFirst и вызывает все его методы. Поскольку TSecond является наследником TFirst, то экземпляр такого типа тоже может передаваться в качестве аргумента процедуре.

В результате работы процедуры (заголовок "TestClass") оказывается, что работа правильно переопределенных виртуальных методов не претерпела никаких изменений, а заново определенные методы StaticProc и Broken работают так, как они реализованы в классе TFirst.

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

[Pascal Warning] Project6.dpr(19): W1010 Method 'Broken' hides virtual method of base type 'TFirst'

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

Тот же эффект возникает и при явном приведении типа, который реализован в третьей части эксперимента (заголовок "Test as").

Из поставленного эксперимента можно сделать несколько важных выводов:

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

Объявление типа «указатель на метод» напоминает объявление процедурного типа с добавлением спецификатора of object.

  TNotifyEvent = procedure(Sender: TObject) of object;

В библиотеке VCL принято первым параметром всех делегируемых методов передавать ссылку на сам объект, вызывающий событие. По соглашению этот первый параметр называется Sender и имеет тип TObject. Он позволяет определить, какой именно объект вызвал обработчик события.

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

procedure TControl.DblClick;
begin
  if Assigned(FOnDblClick) then FOnDblClick(Self);
end; 

Логика работы приведенного метода следующая: сначала с помощью функции Assigned проверяется неравенство ссылки на метод значению Nil. Только в том случае, если адрес обработчика события отличен от nil, его код выполняется. Обратите внимание, что первым параметром обработчику передается ссылка на сам объект с помощью неявной ссылки Self.

В библиотеке VCL объявлено большое количество типов "указателей на методы", которых хватает для диспетчеризации часто возникающих событий, связанных с клавиатурой, мышью и так далее. Однако в ряде случаев возникает необходимость определить свой пользовательский тип "указателя на метод".

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

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

unit Unit8;

interface
type
  TOnResult=procedure(Res: extended) of object;

  TSolver=class
  private
    FOnResult: TOnResult;
  public
    procedure Calc;
  published
    property OnResult:TOnResult read FOnResult write FOnResult;
  end;

implementation

{ TSolver }

procedure TSolver.Calc;
var r: extended;
begin
  r:=random(); // Некоторые вычисления
  if Assigned(FOnResult) then FOnResult(r);
end;

end.

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

unit Unit8;

interface
type
  TSolver=class; // Упреждающее объявление
  TOnResult=procedure(Comonent: TSolver;Res: extended) of object;

  TSolver=class
  private
    FOnResult: TOnResult;
  public
    procedure Calc;
  published
    property OnResult:TOnResult read FOnResult write FOnResult;
  end;

implementation

{ TSolver }

procedure TSolver.Calc;
var r: extended;
begin
  r:=random(); // Некоторые вычисления
  if Assigned(FOnResult) then FOnResult(Self, r);
end;

end.

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

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