Переносимый GUI.

← →
iZEN © (2005-08-16 23:32) [0]

Приветствую.
Сейчас читаю книжку про программную архитектуру пользовательского
интерфеса, и она навевает определённые мысли о эффективном "разделении
труда" между логикой и ГУИ.
(если кому интересно, могу сказать название, она есть в продаже, на
русском языке)

У нас задействованы следующие программные объекты:
+ Системная Очередь (SystemEventQueue) событий (нажатия клавиш,
позиционирование и указания мыши и т.д.);
+ Объекты-события (EventObject"s), которые формируются Очередью в ответ
на любое действие пользователя;
+ Компонент виджета (Object), принимающий от Очереди оповещения о
происходящих, обрабатывающий её Объекты-события;
+ Модель виджета (ObjectModel), инкапсулирующий логику поведения
виджета, хранящий внутреннее состояние (например, взведён ли значёк,
установлена ли радиокнопка, текст поля редактирования, текст метки, флаг
нажата/отпущена кнопка и т.д.);
+ Отображение виджета (ObjectUI), инкапсулирующий визуальное отображение
виджета в зависимости от состояния Модели (например, если влажок
взведён, то рисуется галочка; если кнопка нажата, то рисуется
"утопленная" кнопка, отпущена - "нормальная" кнопка; виджет неактивен -
изображается сереньким цветом и т.д.)
+ Прикладной объект слушателя (ClientListener) с методами обратного
вызова на соответствующие события.

Для начала опишу динамику работы подобной конструкции, а потом вкратце
обосную "статические" принципы архитектуры.

0. Пользователь произвёл какое-то действие в интерфейсе.
1. Системная Очередь событий получает от системы оповещение о действии
пользователя.
2. Системная Очередь событий создаёт Объект-событие и оповещает
Компонент виджета, что, мол, "его надо бы обработать", при этом сама
продолжает следить за системой (вдруг та ещё подкинет событий) -
асинхронное взаимодействие, так сказать.
3. Компонент виджета получает оповещение от Системной Очереди событий и
принимается "доставать" Объект событие из Системной Очереди событий и
обрабатывать его.
4. Обработка Объекта события заключается в установлении нового состояния
Модели виджета и оповещения Прикладных объектов слушателей о
произошедшем событии.
5. Компонент виджета так же следит за состоянием Модели виджета и
непосредственно управляет Отображением виджета в соответствии с этим
состоянием.
6. Модель виджета при изменении своего состояния оповещает Компонент
виджета о необходимости изменения Отображения виджета.

Итого имеем полный цикл обработки действия пользователя и отображения
виджета, который хорошо бы отобразить на диаграмме последовательностей
UML. Но пока обойдусь упрощённой схемой:

System -> SystemEventQueue
|
V
ObjectModel <-> Object -> ObjectUI
|
V
ClientListener

В схеме не показан UIManager, который управляет поведением (Feel) Модели
и отображением (Look) Отображения.

Теперь опишу "статику" архитектуры.

Понятно, что Системная Очередь событий представляет не что иное как нашу
"обёртку" над реальной низкоуровневой системной очередью событий и
представляет собой хранилище-контейнер ждущих обработки событий.

Объект-событие, формируемый Системной Очередью событий, представляет
собой объект, инкапсулирующий всю информацию, произошедшую в системе в
ответ на действие пользователя. Как то: тип события (нажатие/отпускание
клавиши, перемещение мыши, указание мышью с нажатием левой/правой кнопки
и т.д.).

Модель виджета представляет собой логическую модель поведения виджета,
полностью исключая из себя знание о способах отображения виджета на
дисплее. В ней сосредоточена модель поведения (Feel) конкретной
системной оболочки (Motif, Windows, Mac или собственная уникальная).

Отображение виджета является картинкой - объектом, умеющем нарисовать
себя в зависимости от состояния Модели виджета - это то, что
непосредственно видит пользователь на дисплее и с чем он "общается"
посредством клавиатуры и мыши.

Компонент виджета представляет собой ядро, объединяющее вокруг себя нити
управления всем этим хозяйством, но только для Системной Очереди событий
он является слушателем - только от неё он получает события в виде
Объектов событий. Кроме того, Компонент виджета является тем объектом, с
которым непосредственно работает программист - он кладёт его на форму,
назначает свои обработчики событий компонента (например,
объект-обработчик нажатия на кнопку), то есть для программиста Компонент
виджета является своеобразным "фасадом" над сложностями системы: есть
только Компонент виджета и написанные в приложении Прикладные объекты
слушателей.

Прикладной объект слушателя - это объект приложения, который просто
получает оповещения о наступлении определённого события и выполняет
определённую часть бизнес-логики в приложении. Его пишет прикладной
программист.

Управление видом и поведением (LookAndFeel).
Управлением видом и поведением Компонентов виджетов занимается
специальный Менеджер ГУИ (UIManager). Он может настроить поведение
Модели виджета и Отображение виджета в соответствии с поведением (Feel)
и отображением (Look) системного виджета оконного менеджера той или иной
операционной системы. Соответственно, для адекватного предствления
виджета в том или ином стиле необходимо написать лишь необходимые
классы, описывающие поведение (логику, модель) и отображение (способ
отрисовки, вид) каждого из виджетов в конкретной операционной системе.
Таким образом можно получить независимый от операционной системы
интерфейс и, главное, - ОДИНАКОВЫЕ способы работы с ним в приложениях.

Что скажете?

P.S. Продолжаю читать дальше о нюансах отрисовок ГУИ и о том, как
избежать лавинообразного создания Объектов событий.

← →
DrPass © (2005-08-16 23:54) [1]

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

← →
delirium-system-2 (2005-08-17 00:10) [2]

DrPass © (16.08.05 23:54) [1]

http://anatolix.naumen.ru/files/books/design_patterns_rus.zip

Тоже ссылка
http://anatolix.naumen.ru/files/books/interface.zip

Переносимый GUI. Найти похожие ветки