Пользовательский интерфейс современного глубоко продуманного приложения предоставляет возможность прийти к одному и тому же результату несколькими путями. Например, для вставки текстовой строки из буфера обмена в документ Microsoft® Word® пользователь вправе воспользоваться одним из 4-х возможных вариантов: выбрать пункт Вставка главного меню или одноименный пункт контекстного меню, щелкнуть по соответствующей кнопке панели инструментов или нажать сопоставленную операции вставки данных комбинацию быстрых клавиш.
Наличие четырех способов вставки текста из буфера не означает, что в листинге программы четырежды повторен один и тот же код. Такое решение было бы нелепым. Тем более, что в Delphi предусмотрена прекрасная возможность назначения одного и того же обработчика события для нескольких элементов управления. Программисту достаточно описать щелчок по пункту меню и затем подключить к этому событию все остальные элементы управления.
Однако совместное использование одной процедуры обработки события несколькими элементами управления в свою очередь порождает другой недостаток - взаимные ссылки. Наличие большого числа ссылок между элементами управления неблаготворно сказывается на читабельности листинга и в конце концов внесет в исходный код программы путаницу.
Для полноты картины обсудим еще одну небольшую тему. В серьезных программных продуктах состояние элементов управления всегда отражает текущую обстановку. Так, если буфер обмена пуст, то кнопки и пункты меню, отвечающие за вставку данных из буфера, перейдут в пассивный режим и всем своим видом покажут пользователю, что обращение к ним бессмысленно. А теперь представьте, сколько и в каких местах кода надо наставить ловушек для динамического отслеживания наличия в буфере обмена данных, дабы установить соответствующие элементы управления в актуальный
режим. Кроме того, рассматриваемая задача усложняется еще и тем, что к буферу обмена могут одновременно обращаться несколько приложений.
Из вышесказанного следует вывод о наличии проблемы организации централизованного управления приложением. Выходом из сложившейся ситуации может стать:
1. Концентрация управляющего приложением кода «в руках» специального элемента управления, способного предоставлять свои услуги всем остальным элементам управления.
2. Создаваемый центр управления должен обеспечить простой и эффективный способ анализа окружающей обстановки с целью перевода элементов управления в актуальное состояние. Для этого создаваемый элемент должен уметь влиять на ключевые свойства (такие как Enabled, Visible, Checked и т. д.) взаимодействующих с ним визуальных элементов управления.
Начиная с Delphi 4 для решения перечисленных задач в состав VCL были введены особые элементы - командные объекты, основу которых составляет класс TBasicAction. В настоящей главе мы познакомимся с наиболее часто применяемой реализацией команды - классом TAction.
На палитре компонентов мы не обнаружим отдельный командный объект. Потомки TBasicAction нуждаются в специализированном хранилище, в роли которого выступают такие элементы управления, как TActionList (страница Standard,) и TActionManager (страница Additional).
