В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 33
Текст из файла (страница 33)
При этом нужно принимать вовнимание следующие факторы.Действующие силы.• Одна и та же информация может быть представлена по-разному и в несколькихместах для удобства доступа к ней многих различных пользователей, имеющихразные привычки и разные навыки работы с информацией.• Изменения в данных должны немедленно отображаться в различных представленияхэтих данных.• Внесение изменений в пользовательский интерфейс должно быть максимальнопростым, иногда оно даже должно быть возможно прямо во время работыприложения.• Поддержка различных стандартов пользовательского интерфейса и его переносмежду платформами не должны влиять на код, связанный с методами работы сданными и структурой данных приложения.Решение. Выделяется три набора компонентов.
Первый набор — данные, модель данныхили просто модель (model) — соответствует структуре данных предметной области, вкоторой работает приложение. Обязанности этих компонентов: представлять в системеданные и базовые операции над ними. Компоненты второго набора — представления (view)— соответствуют различным способам представления данных в пользовательскоминтерфейсе. Для одних и тех же данных может иметься несколько представлений. Каждомукомпоненту представления соответствует один компонент из третьего набора, обработчик(controller) — компонент, осуществляющий обработку действий пользователей. Такойкомпонент получает команды, чаще всего нажатия клавиш и нажатия кнопок мыши в107областях, соответствующих визуальным элементам управления — кнопкам, элементамменю и пр.
Эти команды он преобразует в действия над данными. В результате каждогодействия требуется обновить все представления всех данных, которые подверглисьизменениям.Структура. Основными ролями компонентов в данном стиле являются модель,представление и обработчик.Компонент-модель моделирует данные приложения, реализует основные операции надними и возможность регистрировать зависимые от него обработчики и представления.
Приизменениях в данных модель оповещает о них все зарегистрированные компоненты.observersObserver0..*Modelmodeldataupdate ()Viewattach (Observer)detach (Observer)notify ()initialize (Model)makeController ()activate ()display ()update ()getData ()viewControllercontrollerinitialize (Model, View)handleEvent ()update ()modelРисунок 51. Структура классов модели, представления и обработчика.Компонент-представление представляет данные в некотором виде для пользователей, читаяих из модели при необходимости, т.е.
при инициализации и после сообщений опроизошедших изменениях. Кроме того, он инициализирует связанный с ним обработчик.Компонент-обработчик обрабатывает действия пользователя, транслируя их в операции надмоделью или запросы на показ некоторых элементов представлений. При оповещении обизменениях в модели он соответствующим образом изменяет собственное состояние,например, делая активными или отключая какие-нибудь кнопки и пункты меню.ControllerModelViewhandle eventchange datanotifyupdateget datadisplayget dataupdateРисунок 52. Сценарий обработки действия пользователя.Динамика.
У системы два базовых сценария работы — инициализация всех компонентов иобработка некоторого действия пользователя с изменением данных и обновлениемсоответствующих им представлений и обработчиков.108ProgramModelViewControllercreatecreateinitialize (model)attachmakeControllercreateinitialize(model, view)attachРисунок 53.
Сценарий инициализации системы.Реализация. Основные шаги реализации следующие.• Отделить взаимодействие человека с системой от базовых функций самой системы.Для этого необходимо выделить структуру данных, с которыми система работает, инабор необходимых для функционирования системы операций над ними.• Реализовать механизм передачи изменений. Для этого можно воспользоватьсяобразцом проектирования Подписчик (иначе называемым Наблюдатель, Observer).• Спроектировать и реализовать необходимые представления.• Спроектировать и реализовать необходимые обработчики действий пользователя.• Спроектировать и реализовать связь между обработчиком и представлением.Обычно представление должно инициализировать соответствующий обработчик.Для этого можно, например, использовать образец проектирования Методпорождения (Factory Method).• Реализовать построение системы из компонентов и инициализацию компонентов.В качестве дополнительных аспектов реализации необходимо рассмотреть следующие.• Динамические представления, создаваемые во время работы приложения.• Подключаемые элементы управления, которые могут быть включены во времяработы приложения.
Например, переключение из режима «новичок» в режим«эксперт».• Инфраструктура и иерархия представлений и обработчиков.Часто имеется готовая библиотека таких компонентов, на основе которых нужностроить собственные представления и обработчики. Эту задачу нужно решать сучетом семантики и возможностей библиотечных компонентов и связей междуними.Кроме того, одни представления могут визуально включать другие, а такжеэлементы управления, с которыми связаны обработчики. Эта визуальная связь частодолжна быть поддержана, например, возможностью переключения фокусапользовательского ввода между отдельными элементами.Необходимо внимательно спроектировать (насколько это возможно, с учетомограничений платформы и библиотек визуальных компонентов) стратегииобработки событий, особенно таких, в которых могут быть одновременнозаинтересованы несколько компонентов, присутствующих на экране.• Возможно, потребуется сделать систему еще более переносимой за счет отделенияее компонентов от конкретных библиотек и платформ.
Для этого нужно разработатьсобственный набор абстрактных визуальных компонентов.109Следствия применения образца.Достоинства.• Возможность иметь несколько представлений одних данных, обновляемых порезультатам воздействий пользователя на одно из них. Все такие представлениясинхронизированы, их показания соответствуют друг другу.• Поддержка подключаемых и динамически изменяемых представлений иобработчиков.• Возможность изменения стилей пользовательского интерфейса во время работы.• Возможность построения каркаса (библиотек визуальных компонентов) дляразработки многих интерактивных приложений.Недостатки.• Возрастание сложности разработки.• Потери в производительности из-за необходимости обработки запросовпользователей сначала в обработчиках, затем в моделях, а затем во всехобновляемых компонентах.• Если не оптимизировать производимые обновления аккуратно, чаще всего в ходеработы происходит много ненужных вызовов операций, обновляющихпредставления и обработчики.• Представления и обработчики связаны очень тесно, из-за чего эти компонентыпочти никогда нельзя переиспользовать по отдельности.• И представления, и обработчики достаточно тяжело использовать безсоответствующей им модели.• Представления и обработчики наверняка потребуют изменений при их переносе надругую платформу или в другую библиотеку элементов графического интерфейсапользователя.• Данный образец тяжело использовать в большинстве средств разработки GUI,поскольку они чаще всего определяют собственные стратегии обработки событий истандартные обработчики для многих событий, например, для нажатия правойкнопки мыши.Примеры.
Впервые этот архитектурный стиль был использован при проектированиибиблиотеки разработки пользовательского интерфейса для языка Smalltalk [1]. С тех порсоздатели множества подобных каркасов и библиотек используют те же принципы.Еще один пример библиотеки для разработки пользовательского интерфейса, построенногона основе данного стиля — библиотека MFC (Microsoft Foundation Classes) от Microsoft. Вней используется более простой вариант стиля — с объединенными представлениями иобработчиками. Такая схема получила название документ-представление (Document-View):документы соответствуют моделям, представления объединяют функции представлений иобработчиков.Такое объединение часто имеет смысл, поскольку представления и обработчики тесносвязаны и практически не могут использоваться друг без друга. Их разделение наотдельные компоненты должно обосновываться серьезными причинами.Последний пример использования этого стиля — архитектура современных Webприложений, т.е.
бизнес-приложений с пользовательским интерфейсом на основе HTML исвязью между отдельными элементами, построенной на базе основных протоколовИнтернет. В ней роль модели играют компоненты, реализующие бизнес-логику и хранениеданных, а роль представлений и обработчиков исполняется HTML-страничками и HTMLформами, статичными или динамически генерируемыми. Далее в этом курсе построениетаких приложений будет рассматриваться более детально, поэтому образец «данныепредставление-обработка» имеет большое значение для дальнейшего изложения.110Образцы проектированияОбразцы проектирования в узком смысле являются типовыми проектными решениями,позволяющими удовлетворить часто встречающиеся требования к гибкости приложений иреализовать возможности их расширения за счет специальных форм организации классов и ихсвязей.Далее мы в деталях рассмотрим образец проектирования «подписчик». О другом примере,«адаптере», было рассказано в начале предыдущей лекции.ПодписчикНазвание.
Подписчик (subscriber) или подписчик-издатель (publisher-subscriber). Известентакже под названиями «наблюдатель» (observer), «слушатель» (listener) или «подчиненные»(dependents).Назначение. Реализация системы, в которой нужно поддерживать согласованнымисостояния большого числа объектов.
Чаще всего при этом достаточно много компонентовзависит от небольшого набора данных. Можно было бы связать их явно, введя обращенияко всем компонентам, которые должны знать об изменениях, при каждом внесенииизменений, но полученная система станет очень жесткой. Добавление нового компонентапотребует сделать изменения во всех местах, от которых он зависит. Предлагаемое врамках данного образца решение основано на гибкой связи между субъектом (от которогозависят другие компоненты) и этими зависимыми компонентами, называемымиподписчиками. Здесь нужно принимать во внимание следующие факторы.Действующие силы.• Об изменениях в состоянии некоторого компонента должны узнавать один илинесколько других компонентов.• Количество и конкретный вид компонентов, которые должны оповещаться об этихизменениях, заранее не известны или могут быть изменены во время работыприложения.• Проведение зависимыми компонентами время от времени явных запросов опроизошедших изменениях неэффективно.• Источник информации (субъект или издатель) не должен быть тесно связан сосвоими подписчиками или зависим от них.Решение.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
