Главная страница | Контакты | Случайная страница Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Операции пользователя

Часть функциональности Lexi доступна через WYSIWYG-представление до­кумента. Вы вводите и удаляете текст, перемещаете точку вставки и выбираете участки текста, просто указывая и щелкая мышью или нажимая клавиши. Другая часть функциональности доступна через выпадающие меню, кнопки и клавиши-ускорители. К этой категории относятся такие операции:

а создание нового документа;

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

а изменение форматирования текста, например, установка режима выравни­вания; а завершение приложения и др.

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

Проектирование редактора документов

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

Ситуация осложняется еще и тем, что Lexi должен поддерживать операции отмены и повтора¹ большинства, но не всех функций. Точнее, желательно уметь отменять операции модификации документа (скажем, удаление), которые из-за оплошности пользователя могут привести к уничтожению большого объема дан­ных. Но не следует пытаться отменить такую операцию, как сохранение чертежа или завершение приложения. Мы также не хотели бы налагать произвольные огра­ничения на число уровней отмены и повтора.

Ясно, что поддержка пользовательских операций распределена по всему при­ложению. Задача в том, чтобы найти простой и расширяемый механизм, удовлет­воряющий всем вышеизложенным требованиям.

Инкапсуляция запроса

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

Предположим, что такие реагирующие глифы являются экземплярами под­класса Menu It em класса Glyph и что свою работу они выполняют в ответ на за­прос клиента². Для выполнения запроса может потребоваться вызвать одну операцию одного объекта или много операций разных объектов. Возможны и промежуточные варианты.

Мы могли бы определить подкласс класса Menu It em для каждой операции пользователя, а затем жестко закодировать каждый подкласс для выполнения со­ответствующего запроса. Но вряд ли это правильно: нам не нужен подкласс Menu It em для каждого запроса, точно так же, как не нужен отдельный подкласс для каждой строки в выпадающем меню. Помимо всего прочего, такой подход тес­но привязывает запрос к конкретному элементу пользовательского интерфейса, поэтому выполнить тот же запрос через другой интерфейс будет нелегко.

Предположим, что на последнюю страницу документа вы можете перейти, выбрав соответствующий пункт из меню или щелкнув по значку с изображением страницы в нижней части окна Lexi (для коротких документов это удобно). Если мы ассоциируем запрос с подклассом Menu It em с помощью наследования, то долж­ны сделать то же самое и для значка страницы, и для любого другого виджета, который способен послать подобный запрос. В результате число классов будет примерно равно произведению числа типов виджетов на число запросов.

¹ Под повтором (redo) понимается выполнение только что отмененной операции.

² Концептуально клиентом является пользователь Lexi, но на самом деле это просто какой-то другой
объект (например, диспетчер событий), который управляет обработкой ввода пользователя.

Операции пользователя

Нам не хватает механизма параметризации пунктов меню запросами, которые они должны выполнять. Таким способом удалось бы избежать разрастания числа подклассов и обеспечить большую гибкость во время выполнения. Параметризо­вать Menu It em можно вызываемой функцией, но это решение неполно по трем причинам:

а в нем не учитывается проблема отмены/повтора;

а с функцией трудно ассоциировать состояние. Например, функция, изменя­ющая шрифт, должна «знать», какой именно это шрифт;

а функции с трудом поддаются расширению, а использовать их части тоже затруднительно.

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

Класс Command и его подклассы

Сначала определим абстрактный класс Command, который будет предостав­лять интерфейс для выдачи запроса. Базовый интерфейс включает всего одну аб­страктную операцию Execute. Подклассы Command по-разному реализуют эту операцию для выполнения запросов. Некоторые подклассы могут частично или полностью делегировать работу другим объектам, а остальные выполняют запрос сами (см. рис. 2.11). Однако для запрашивающего объект Command — это всего лишь объект Command, все они рассматриваются одинаково.

Проектирование редактора документов

Теперь в классе Menu It em может храниться объект, инкапсулирующий за­прос (рис. 2.12). Каждому объекту, представляющему пункт меню, мы передаем экземпляр того из подклассов Command, который соответствует этому пункту, точ­но так же, как мы задаем текст, отображаемый в пункте меню. Когда пользователь выбирает некоторый пункт меню, объект Menu It em просто вызывает операцию Execute для своего объекта Command, тем самым предлагая ему выполнить за­прос. Заметим, что кнопки и другие виджеты могут пользоваться объектами Command точно так же, как и пункты меню.

Рис. 2.12. Отношение между классами Menultem и Command

Отмена операций

Для того чтобы отменить или повторить команду, нужна операция Unexecute в интерфейсе класса Command. Ее выполнение отменяет все, что было сделано пре­дыдущей командой Execute. При этом используется информация, сохраненная операцией Execute. Так, при команде FontCommand операция Execute была бы должна сохранить координаты участка текста, шрифт которого изменялся, а равно и первоначальный шрифт (или шрифты). Операция Unexecute класса FontCommand должна была бы восстановить старый шрифт (или шрифты) для этого участка текста.

Иногда определять, можно ли осуществить отмену, необходимо во время вы­полнения. Скажем, запрос на изменение шрифта выделенного участка текста не производит никаких действий, если текст уже отображен требуемым шрифтом. Предположим, что пользователь выбрал некий текст и решил изменить его шрифт на случайно выбранный. Что произойдет в результате последующего запроса на отмену? Должно ли бессмысленное изменение приводить к столь же бессмыслен­ной отмене? Наверное, нет. Если пользователь повторит случайное изменение шрифта несколько раз, то не следует заставлять его выполнять точно такое же число отмен, чтобы вернуться к последнему осмысленному состоянию. Если сум­марный эффект выполнения последовательности команд нулевой, то нет необхо­димости вообще делать что-либо при запросе на отмену.

Для определения того, можно ли отменить действие команды, мы добавим к интерфейсу класса Command абстрактную операцию Reversible (обратимая), которая возвращает булево значение. Подклассы могут переопределить эту опе­рацию и возвращать true или false в зависимости от критерия, вычисляемого во время выполнения.