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

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

Как должно выглядеть приложение - это лишь один из многих вопросов, вста­ющих при переносе приложения на новую платформу. Еще одна проблема из той же серии - оконная среда, в которой работает Lexi. Данная среда создает иллю­зию наличия нескольких перекрывающихся окон на одном растровом дисплее. Она распределяет между окнами площадь экрана и направляет им события кла­виатуры и мыши. Сегодня существует несколько широко распространенных и во многом не совместимых между собой оконных систем (например, Macintosh, Pre­sentation Manager, Windows, X). Мы хотели бы, чтобы Lexi работал в любой окон­ной среде по тем же причинам, по которым мы поддерживаем несколько стандар­тов внешнего облика.

Можно ли воспользоваться абстрактной фабрикой?

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

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

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

стандарта (например, Mot if ScrollBar иMacScrollBar) от абстрактного клас­са (допустим, ScrollBar). Предположим, однако, что у нас уже есть несколько иерархий классов, полученных от разных поставщиков, - по одной для каждого стандарта. Маловероятно, что данные иерархии будут совместимы между собой. Поэтому отсутствуют общие абстрактные изготавливаемые классы для каждого вида виджетов (ScrollBar, Button, Menu и т.д.). А без них фабрика классов работать не может. Необходимо, чтобы иерархии виджетов имели единый набор абстрактных интерфейсов. Только тогда удастся правильно объявить операции Create... в интерфейсе абстрактной фабрики.

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

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

Инкапсуляция зависимостей от реализации

В разделе 2.2 мы ввели класс Window для отображения на экране глифа или структуры, состоящей из глифов. Ничего не говорилось о том, с какой оконной системой работает этот объект, поскольку в действительности он вообще не свя­зан ни с одной системой. Класс Window инкапсулирует понятие окна в любой оконной системе:

а операции для отрисовки базовых геометрических фигур; а возможность свернуть и развернуть окно;

Таблица 2.3. Интерфейс класса Window
Обязанность Операции

управление окнами virtual void Redraw()

virtual void Raise()

virtual void Lower()

virtual void IconifyO

virtual void DeiconifyO

графика virtual void DrawLine(...)

virtual void DrawRect(...)

virtual void DrawPolygon(...)

virtual void DrawText(...)