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


Предвычисленные командные объекты - часть 2


create commands.make (1, command_count) create {LINE_INSERTION} requested.make; commands.put (requested, 1) create {STRING_REPLACE} requested.make; commands.put (requested, 2) ... И так для каждого типа команд ...

Заметьте, при этом подходе процедуры создания не должны иметь аргументов; если командный класс имеет атрибуты, то следует устанавливать их значения позднее в специально написанных процедурах, например li.make (input_text, cursor_position), где li типа LINE_INSERTION.

Теперь исчезла необходимость применения разбора случаев и ветвящихся инструкций if или inspect. Приведенная выше инициализация служит теперь точкой Единственного Выбора. Теперь реализацию абстрактной операции "Создать подходящий командный объект и присоединить его к requested" можно записать так:

requested := clone (commands @ code)

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

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

Если, однако, использовать предложенную технику, полностью отделяющую аргументы команды от командных объектов (так что список истории содержит экземпляры COMMAND_INSTANCE, а не COMMAND), то тогда в получении клонов нет необходимости, и можно перейти к использованию ссылок на оригинальные объекты из массива:

requested:= commands @ code

В длительных сессиях такая техника может давать существенный выигрыш.




Начало  Назад  Вперед



Книжный магазин