98/97: Отделяйте интерфейс пользователя от кода

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

"По мотивам" этой серии я хотел бы озвучить очередной факт из "98-ми вещей, которые должен знать каждый Delphi программист" (где остальные 97 вещей взяты из указанной выше серии ;) ). Это действительно must-know, но он не покрыт в указанной серии (видимо потому, что он достаточно специфичен?).

Типичный код в "типичной" Delphi-программе

В любом случае, надо сказать, что возникает это не на пустом месте - в определённом смысле Delphi "поощряет" подобную практику. Заключается она в следующем: вы пишете весь код программы в обработчиках событий формы. Например:

procedure TForm1.Button1Click(Sender: TObject);
var
  FS: TFileStream;
  // ...
begin
  FS := TFileStream.Create(Edit1.Text, fmOpenRead or fmShareDenyWrite);
  try
    ... // какая-то обработка файла из Edit1
  finally
    FreeAndNil(FS);
  end;
end;

Зачастую вообще весь код программы находится в обработчиках событий.

Что с этим не так?

Ну, что не так с этим подходом? Ведь когда ты щёлкаешь по кнопке на форме, Delphi услужливо генерирует и ассоциирует обработчик события, открывает редактор, позиционирует курсор на begin/end, как бы приглашая вас к написанию тут логики программы.

Давайте считать:

• Ваш код зависит от формы. Нужна ли вам форма, чтобы обработать файл? Нет. Форма служит только для ввода параметров и запуска процесса работы. Отсюда следует несколько следующих пунктов.
• Если к вам подойдёт начальник и скажет: "слушай, тут заказчик попросил сделать консольный вариант твоей программки - они хотят запускать её в своих скриптах автоматизации", то скажете ли вы ему, что это потребует написание программы с нуля? "Ну у тебя же всё готово?" Да, готово. Только совершенно не предназначено для таких изменений.
• Потом к вам снова подойдёт начальник и скажет: "слушай, нашего заказчика уже достало, что после каждого изменения в твоей программе что-то плывёт. Давай-ка ты напишешь тестики, которые закрепят основной функционал, ага?" Уммм... вот только чтобы запустить тест вам придётся создать форму, ввести данные в контролы на форме, щёлкнуть по кнопке... и ещё как-то распознать результат с формы!
• И снова к вам подходит начальник и говорит: "слушай, может я тебя и достал, но у заказчика многопроцессорная машина, и они хотят, чтобы можно было открыть несколько окон с обработкой - пусть машина себе молотит по четыре файла сразу". Упс. Вот только у вас всё завязано на форму, которая только одна, да и вообще вы использовали глобальные переменные.

Это только самые яркие примеры. К примеру, не слишком красивые ситуации будут получаться, когда вам придётся изменять интерфейс - и перелопачивать весь код, который с ним работает. Ещё пример? Ну, размещение всего кода в обработчиках событий ведёт к непомерному их разрастанию - часто вся логика программы будет заключаться в огромном монолитном куске кода, в котором без комментариев просто не разобраться. Или, ещё пример: потом вы обнаружите, что обработка сколько-нибудь больших файлов занимает время и захотите вынести это дело в фоновый поток, чтобы не тормозить интерфейс, и... не сможете это сделать, потому что всё завязано на форме, а VCL однопоточна, и снова всё придётся переписывать...

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

Нет, подобный подход отлично работает в программке из 10 строк, которую вы написали, чтобы проверить идею, но совершенно неприменим в реальных проектах. К сожалению, многие Delphi-программисты в отсутствии какого-либо образования (самостоятельного или же в учебном заведении) просто не подозревают, что можно делать как-то по-другому! Я пишу сейчас эти строки, чтобы в следующий раз кинуть в кого-нибудь ссылкой :D

Что с этим делать?

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

Что значит "разграничить"? В простейшем случае это означает выполнение правила "код логики программы не должен ссылаться на интерфейс пользователя". К примеру, в нашем коде в начале поста рабочий код ссылается на Edit1 - ведь там лежит имя файла. Так вот, такого быть не должно: а вдруг вам имя файла передают параметром в командной строке? А вдруг его задаёт модульный тест?

Как это можно сделать? Ну, подумайте сами: если вы не можете ссылаться на интерфейс пользователя, то данные, приходящие с этого интерфейса, нам должен кто-то передавать. Оставим пока этого "кто-то": куда он должен передавать данные? Если вы практикуете процедурный подход, то, наверное, он должен передавать вам данные в параметрах. Если вы практикуете ООП, то к указанному способу добавляется ещё два: данные могут передаваться в конструктор или через свойства объекта. Окей, если вы сейчас читаете этот пост, то навряд ли вы вообще практикуете эти подходы - скорее вы придерживаетесь подхода "пиши весь код в Button1Click" ;) Оставим пока в стороне покрытый мхом процедурный подход - обратимся к ООП.

ООП говорит нам, что у нас должен быть объект, который будет заключать в себе логику программы. Объект, заключающий в себе интерфейс пользователя, у нас уже есть - это наша форма TForm1. Тогда создаём новый модуль File/New/Unit и начинаем писать новый объект, имя которого, за неимением пока лучших вариантов, пусть будет TWorker (ну или TИмяВашейПрограммыWorker):

unit Unit2;

interface

type
  TWorker = class
  end;

implementation

end.

Зачем нужен отдельный модуль: почему бы не пихнуть класс в Unit1? В-принципе, можно. Но лучше так не делать. Вынос рабочего кода в отдельный модуль имеет одно существенное преимущество (оно, впрочем, не единственное): форсирование разделение кода. Иными словами, вы не должны указывать в uses модуля Unit2 свой модуль с формой (Unit1) - это автоматически обеспечит выполнение требования "рабочий код не должен зависеть от интерфейса". В противном случае (размещение нового класса прямо в модуле с формой) вы можете ошибочно использовать в рабочей логике ссылки на форму.

Далее, вы смотрите, что должна уметь делать ваша программа - и создаёте по методу на каждое действие. Давайте пока ограничимся не слишком сложной программой, которая выполняет небольшой диапазон действий. Понятно, что для больших программ вы не ограничитесь одним объектом - у вас их будет много, и имена они будут тогда иметь поосмысленнее, а не просто TWorker (например, TDocument, TDocumentPrinter, TDocumentOptions и т.п.).

Для первого приближения вполне можно взять методы, которые копируют действия, которые вы выполняли в обработчиках событий. Как этот код будет работать с данными, которые сейчас у вас задаются на форме? Ну, есть несколько вариантов:

• Вы передаёте их параметрами в метод.
• Вы передаёте их в конструктор объекта.
• Вы передаёте их через свойства объекта.

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

...

type
  TWorker = class
    procedure ProcessFile(const AFileName: String { и другие параметры, если надо } );
  end;

implementation

procedure TWorker.ProcessFile(const AFileName: String { ... } );
var
  FS: TFileStream;
  // ...
begin
  FS := TFileStream.Create(AFileName, fmOpenRead or fmShareDenyWrite);
  try
    ... // какая-то обработка файла AFileName
  finally
    FreeAndNil(FS);
  end;
end;

...

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

Как использовать такой объект в программе? Ну, во-первых, очевидно, что надо вписать имя модуля Unit2 в uses нужного модуля :D Далее вариантов немного:

• Создать объект на всё время жизни формы.
• Создать объект только на время, в момент вызова обработчика события.

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

Ну, наш пример совсем прост, поэтому второй случай будет в тему:

procedure TForm1.Button1Click(Sender: TObject);
var
  Worker: TWorker;
begin
  Worker := TWorker.Create;
  try
    Worker.ProcessFile(Edit1.Text { и другие параметры, если надо });
  finally
    FreeAndNil(Worker);
  end;
end;

Если же вы выберите первый способ, то FormCreate и FormDestroy, вероятно, будут хорошими кандидатами для помещения в них создания и удаления объекта:

type
  TForm1 = class(TForm)
  ...
  private
    FWorker: TWorker;
  end;

...

procedure TForm1.FormCreate(Sender: TObject);
begin
  FWorker := TWorker.Create;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  FWorker.ProcessFile(Edit1.Text { ... });
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  FWorker.КакойТоДругойМетод({ ... });
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  FreeAndNil(FWorker);
end;

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

• Чем объект лучше простой процедуры ProcessFile?
• Чем метод ProcessFile в TWorker лучше метода ProcessFile в TForm1?
• И т.д....

Какой код должна выполнять форма?

Разумеется, не весь код из обработчиков событий нужно выносить в рабочие объекты. Какой код нужно оставить? В форме должен остаться код, который манипулирует самой формой (в общем случае: UI вообще) и вызывает методы рабочих объектов. Например:

procedure TForm1.Button1Click(Sender: TObject);
begin
  Button1.Enabled := False; // не должно находится в TWorker,
                            // т.к. это user interface, а не логика программы
  try
    FWorker.ProcessFile(Edit1.Text { ... });
  finally
    Button1.Enabled := True;
  end;
end;

На самом деле...

А на самом деле я рекомендую вам почитать банду четырёх о шаблонах проектирования. Я действительно рекомендую это сделать, потому что эта заметка - очень краткое и упрощённое изложение, чья цель - дать начальное представление, а не служить мануалом. В частности, я ничего не сказал, что делать, если вашему рабочему коду нужно взаимодействовать с пользователем (показать сообщение или спросить дополнительные данные).

Читать далее: "Дружественность" в Delphi.