Шаблоны в Delphi (но не дженерики)

Об этом уже писали: http://edn.embarcadero.com/article/27603 или вот http://18delphi.blogspot.ru/2013/09/templates-in-object-pascal.html.

Напишу своими словами, надеюсь в доступной для массового читателя форме.

Итак, допустим у нас есть пара классов: TSomeType1 и TSomeType2, которые объявлены в SomeUnit.pas. И допустим, что эти классы имеют одинаковый набор некоторых свойств и методов, но при этом эти свойства и методы не объявлены у их общего предка. К примеру, пусть будет так:

unit SomeUnit;

interface 

type
  TSomeType1 = class(TObject)
  // ..
  public
    procedure DoSomething;
  end;

  TSomeType2 = class(TObject)
  // ..
  public
    procedure DoSomething;
  end;

  ..
end.

Здесь видим метод DoSomething, который есть у обоих классов. Но это два разных метода.

HINT: И допустим, что у нас нет возможности вносить изменения в SomeUnit.pas. Это важно для понимания, почему именно такой подход я описываю.

А теперь допустим, что у нас есть задача: написать класс, который будет работать с экземплярами наших классов, вызывая у них DoSomething (по некоторым событиям). А т.к. TSomeType1 и TSomeType2 – это разные классы, то нам придётся писать два новых класса. Назовём их T1 и T2 соответственно. Как это можно сделать? Ну, например, в лоб (файл MyUnit.pas):

unit MyUnit;

uses SomeUnit;

interface

type
  T1 = class(TObject)
  private
    FObject: TSomeType1;
  public
    constructor Create(AObject: TSomeType1);
  end;
  
  T2 = class(TObject)
  private
    FObject: TSomeType2;
  public
    constructor Create(AObject: TSomeType2);
  end;

implementation

constructor T1.Create(AObject: TSomeType1);
begin
  FObject := AObject;
  FObject.DoSomething;
end;

constructor T2.Create(AObject: TSomeType2);
begin
  FObject := AObject;
  FObject.DoSomething;
end;

end.

HINT: Здесь вызов DoSomething происходит всего один раз в конструкторе классов T1 и T2. Это совсем не практично, но это всего лишь пример, на котором я хочу продемонстрировать описываемую технику.

И использовать это где-то в коде так:

uses SomeUnit, MyUnit;
..
var
  Obj1: TSomeType1;
  Obj2: TSomeType2;
  ObjA: T1;
  ObjB: T2;
..
  ObjA := T1.Create(Obj1);
  ObjB := T2.Create(Obj2);
..

А теперь представьте, что наши классы T1 и T2 делают гораздо больше работы. Т.е. кода будет больше. Но при этом, код будет совпадать. Налицо – дублирование кода. Как же его избежать?

Мысль первая – обобщения

Попробуем обобщения, они же – дженерики. Наш MyUnit.pas будет выглядеть так:

unit MyUnit;

uses SomeUnit;

interface

type
  TX<T> = class(TObject)
  private
    FObject: T;
  public
    constructor Create(AObject: T);
  end;
  T1 = TX<TSomeType1>;
  T2 = TX<TSomeType2>;
  
implementation

constructor TX.Create(AObject: T);
begin
  FObject := AObject;
  FObject.DoSomething;
end;

end.

Но, к сожалению, такой код не скомпилируется. Потому что для компиляции строки FObject.DoSomething нужно знать, что метод DoSomething есть у типа T, а этого компилятор знать просто не может. И я не нашел способов это каким-либо образом определить. Можно явно указать, от какого класса должен быть унаследован тип T, или какой интерфейс тип T должен поддерживать.  Но в нашем примере это не подходит (мы же не можем вносить правки в SomeUnit.pas, помните?).

UPD: В комментариях мне напомнили ещё и про RTTI. Да, начиная с Delphi 2010, с использованием RTTI можно достучаться даже до приватных полей объекта. Но мне это не нравится в плане читаемости кода и скорости исполнения.

Мысль вторая – шаблоны кода

Попробуем include-файлы (обычные inc-файлы, которые существуют в Delphi в наследство от Pascal’я). Идея простая: дублирующийся код выносим в inc-файл, который подставляем в нужных нам местах директивой {$I filename}. Смотрите, создадим файл X.inc с таким содержанием:

  type
    TX = class(TObject)
    private
      FObject: TReplacement;
    public
      constructor Create(AObject: TReplacement);
    end;

implementation

constructor TX.Create(AObject: TReplacement);
begin
  FObject := AObject;
  FObject.DoSomething;
end;

end.

Этот код надо будет подставить два раза. Но в один файл это не получится сделать, поэтому создаём два вспомогательных файла.

Файл "A.pas":

unit A;

interface

uses SomeUnit;

type
  TX = class; // forward declaration
  T1 = TX;
  TReplacement = TSomeType1;
  {$i X.inc}

Файл "B.pas":

unit B;

interface

uses SomeUnit;

type
  TX = class; // forward declaration
  T2 = TX;
  TReplacement = TSomeType2;
  {$i X.inc}

HINT: Тут я немного схитрил. Чтобы не делать два inc-файла (один для интерфейсной части, а второй для части реализации – как это предлагают авторы по ссылкам выше), в модулях A и B, перед включением inc-файла, добавил forward declaration (строка номер 8) для класса TX (который и описывается в inc-файле). После чего этого я могу напрямую сослаться на этот класс (ещё до его интерфейсной части – строка 9). В строке 10 указывается тот тип данных, который будет использоваться inc-файлом вместо TReplacement.

HINT: Если Вы не совсем понимаете, что тут происходит, то просто подставьте содержимое файла X.inc в файлы A.pas и B.pas вместо директивы {$i X.inc}. И Вы увидите, что получилось два полноценных модуля.

HINT: Строго говоря, дублирования исполняемого кода (как и с дженериками) мы не избежали. При компиляции нашего примера inc-файл будет подставлен два раза. Но нам удалось избежать дублирования на уровне исходного кода – а это, порой, многого стоит.

После этого, наш модуль MyUnit.pas надо переписать, он станет таким:

unit MyUnit;

uses A, B;

interface

type
  T1 = A.T1;
  T2 = B.T2;

implementation

end.

И мы можем его использовать точно так же, как это было показано выше.

Зачем это нужно

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

Например, в VCL есть компонент TCombobox. В режиме Style = csSimple или Style = csDropdown он работает как обычный TEdit. И у TCombobox и у TEdit есть набор схожих свойств: MaxLength, SelStart, SelLength, SelText и т.п. Но эти свойства объявлены не в их общем предке (TWinControl), а в классах TCustomComboBox и TCustomEdit соответственно.

В предыдущей заметке я описывал, как можно немного изменить стандартное поведение свойства MaxLength для наследников от TCustomEdit (т.е. TEdit, TMemo и т.п.). А для того, чтобы его можно было применить и к TCustomComboBox – воспользуемся описанной выше техникой.

Тестовое приложение:

Скачать: исходник или тестовое приложение.

Плюсы и минусы данной техники

Плюсы:

• Мы решили частную задачу, когда нет возможности (или нет желания) внести изменения в исходный код сторонней библиотеки.
• Мы избежали дублирования кода.

Минусы:

• Когда мы выносим код в inc-файл, надо чуть больше воображения, чем обычно: придумать имена для файлов и замещаемых типов, а также представлять, как это будет выглядеть в итоге.
• IDE, работая с inc-файлами, заранее не знает, в какие места этот inc-файл будет подставляться. Как следствие – тут не работает CodeInsight, могут возникнуть проблемы с рефакторингом и автоматическим форматированием кода.

И такой нюанс. Отладчик с inc-файлами работает так же, как и с обычными pas-файлами. Но (как и с дженериками) ставя точку останова в inc-файле, это точка включается и для T1 и для T2. Решается указанием условия для точки останова, например: Self is T1.