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

Оформление пользовательского интерфейса

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

Оформление пользовательского интерфейса

Прозрачное обрамление

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

Можно было бы добавить рамку к классу Composition, породив от него но­вый подкласс BorderedComposition. Точно так же можно было бы добавить и интерфейс прокрутки, породив подкласс ScrollableCompositiont Если же мы хотим иметь и рамку, и полосу прокрутки, следовало бы создать подкласс BorderedScrollableComposition, и так далее. Если довести эту идею до ло­гического завершения, то пришлось бы создавать отдельный подкласс для каж­дой возможной комбинации элементов оформления. Это решение быстро пере­стает работать, когда количество разнообразных декораций растет.

С помощью композиции объектов можно найти куда более приемлемый и гиб­кий механизм расширения. Но из каких объектов составлять композицию? По­скольку известно, что мы оформляем существующий глиф, то и сам элемент оформ­ления могли бы сделать объектом (скажем, экземпляром класса Border). Следовательно, композиция может быть составлена из глифа и рамки. Следую­щий шаг - решить, что является агрегатом, а что - компонентом. Допустимо счи­тать, что рамка содержит глиф, и это имеет смысл, так как рамка окружает глиф на экране. Можно принять и противоположное решение - поместить рамку внутрь глифа, но тогда пришлось бы модифицировать соответствующий подкласс класса Glyph, чтобы он «знал» о наличии рамки. Первый вариант - включение глифа в рамку - позволяет поместить весь код для отображения рамки в классе Border, оставив остальные классы без изменения.

Как выглядит класс Border? Тот факт, что у рамки есть визуальное представ­ление, наталкивает на мысль, что она должна быть глифом, то есть подклассом клас­са Glyph. Но есть и более настоятельные причины поступить именно таким обра­зом: клиентов не должно волновать, есть у глифов рамки или нет. Все глифы должны трактоваться единообразно. Когда клиент сообщает простому глифу без рамки о необходимости нарисовать себя, тот делает это, не добавляя никаких эле­ментов оформления. Если же этот глиф заключен в рамку, то клиент не должен об­рабатывать рамку как-то специально; он просто предписывает составному глифу выполнить отображение точно так же, как и простому глифу в предыдущем случае. Отсюда следует, что интерфейс класса Border должен соответствовать интерфей­су класса Glyph. Чтобы гарантировать это, мы и делаем Border подклассом Glyph.

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