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

Поддержка нескольких стандартов внешнего облика

При проектировании системы приходится сталкиваться с серьезной пробле­мой: как добиться переносимости между различными программно-аппаратными платформами. Перенос Lexi на другую платформу не должен требовать капиталь­ного перепроектирования, иначе не стоит за него и браться. Он должен быть мак­симально прост.

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

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

Поддержка нескольких стандартов

Абстрагирование создания объекта

Все, что мы видим и с чем можем взаимодействовать в пользовательском ин­терфейсе Lexi, - это визуальные глифы, скомпонованные в другие, уже невидимые глифы вроде строки (Row) и колонки (Column). Невидимые глифы содержат види­мые - скажем, кнопку (Button) или символ (Character) - и правильно распола­гают их на экране. В руководствах по стилистическому оформлению много гово­рится о внешнем облике и поведении так называемых «виджетов» (widgets); это просто другое название таких видимых глифов, как кнопки, полосы прокрутки и меню, выполняющих в пользовательском интерфейсе функции элементов управ­ления. Для представления данных виджеты могут пользоваться более простыми глифами: символами, окружностями, прямоугольниками и многоугольниками.

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

а набор абстрактных подклассов класса Glyph для каждой категории видже­тов. Например, абстрактный класс ScrollBar будет дополнять интерфейс глифа с целью получения операций прокрутки общего вида, a Button - это абстрактный класс, добавляющий операции с кнопками;

а набор конкретных подклассов для каждого абстрактного подкласса, в кото­рых реализованы стандарты внешнего облика. Так, у Scrol IBar могут быть подклассы MotifScrollBar и PMScrollBar, реализующие полосы про­крутки в стиле Motif и Presentation Manager соответственно.

Lexi должен различать глифы-виджеты для разных стилей внешнего оформле­ния. Например, когда необходимо поместить в интерфейс кнопку, редактор должен инстанцировать подкласс класса Glyph для нужного стиля кнопки (Mot i f Button, PMButton, MacButton и т.д.).

Ясно, что в реализации Lexi это нельзя сделать непосредственно, например, вызвав конструктор, если речь идет о языке C++. При этом была бы жестко зако­дирована кнопка одного конкретного стиля, значит, выбрать нужный стиль во время выполнения оказалось бы невозможно. Кроме того, мы были бы вынужде­ны отслеживать и изменять каждый такой вызов конструктора при переносе Lexi на другую платформу. А ведь кнопки - это лишь один элемент пользовательского интерфейса Lexi. Загромождение кода вызовами конструкторов для разных клас­сов внешнего облика вызывает существенные неудобства при сопровождении. Стоит что-нибудь пропустить - и в приложении, ориентированном на платформу Мае, появится меню в стиле Motif.

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

Фабрики и изготовленные классы

В Motif для создания экземпляра глифа полосы прокрутки обычно было до­статочно написать следующий код.на C++:

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

ScrollBar* sb = new MotifScrollBar;

Ho такого кода надо избегать, если мы хотим минимизировать зависимость Lexi от стандарта внешнего облика. Предположим, однако, что sb инициализиру­ется так:

ScrollBar* sb = guiFactory->CreateScrollBar();

где guiFactory - CreateScrollBar объект класса Mot if Factory. Операция

возвращает новый экземпляр подходящего подкласса ScrollBar, который соот­ветствует желательному варианту внешнего облика, в нашем случае - Motif. С точки зрения клиентов результат тот же самый, что и при прямом обращении к конструктору Motif ScrollBar. Но есть и существенное отличие: нигде в коде ⁴ больше не упоминается имя Motif. Объект guiFactory абстрагирует процесс создания не только полос прокрутки для Motif, но и любых других. Более того, guiFactory не ограничен изготовлением только полос прокрутки. Его можно применять для производства любых виджетов, включая кнопки, поля ввода, меню и т.д.

Все это стало возможным, поскольку Mot if Factory является подклассом GUIFactory - абстрактного класса, который определяет общий интерфейс для создания глифов-виджетов. В нем есть такие операции, как CreateScrollBar и CreateButton, для инстанцирования различных видов виджетов. Подклассы GUIFactory реализуют эти операции, возвращая глифы вроде Mot if ScrollBar и PMButton, которые имеют нужный внешний облик и поведение. На рис. 2.9 по­казана иерархия классов для объектов guiFactory.

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

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

Когда вариант внешнего облика известен на этапе компиляции, то guiFactory можно инициализировать простым присваиванием в начале программы:

GUIFactory* guiFactory = new MotifFactory;

Если же пользователю разрешается задавать внешний облик с помощью стро­ки-параметра при запуске, то код создания фабрики мог бы выглядеть так:

GUIFactory* guiFactory;

const char* styleName = getenv("LOOK_AND_FEEL");

// получаем это от пользователя или среды при запуске