Lecture08 (Лекции по Технологии программирования. Компонентный подход)

Технологии программирования. Компонентный подходВ. В. КуляминЛекция 8. Образцы проектирования (продолжение)АннотацияРассматриваются дополнительные примеры образцов: архитектурный стиль «данные–представление–обработка», ряд образцов проектирования, идиом и образцов организации работ.Ключевые словаОбразец проектирования, архитектурный стиль, идиома, образец организации, образец процесса,архитектурный стиль «данные-представление-обработка», образец проектирования «подписчик»,идиома «шаблонный метод», инспекция программ по Фагану.Текст лекцииВ этой лекции мы продолжим разбирать примеры образцов — рассмотрим детальноархитектурный стиль «Данные–представление–обработка», а также примеры тех видов образцов,которые не уместились в предыдущую лекцию: образцов проектирования в узком смысле, идиом иобразцов организации.Данные–представление–обработкаНазвание.

Данные–представление–обработка (model–view–controller, MVC).Назначение. Интерактивные приложения с гибким интерфейсом пользователя. Требованияк пользовательскому интерфейсу в интерактивных приложениях меняются чаще всего.Разные пользователи имеют разные наборы требований. В несколько меньшей степени этокасается методов обработки данных, лежащих в основе таких приложений, — визуальноепредставление управляющих элементов может меняться вместе с интерфейсом, а самивыполняемые действия зависят от бизнес-логики и предметной области, и поэтому болееустойчивы.

Наименее подвержена изменениям модель данных, с которыми работаетприложение.Поэтому для увеличения гибкости и удобства изменений в таких приложениях необходимосоответствующим образом разделить их компоненты. При этом нужно принимать вовнимание следующие факторы.Действующие силы.• Одна и та же информация может быть представлена по-разному и в несколькихместах для удобства доступа к ней многих различных пользователей, имеющихразные привычки и разные навыки работы с информацией.• Изменения в данных должны немедленно отображаться в различных представленияхэтих данных.• Внесение изменений в пользовательский интерфейс должно быть максимальнопростым, иногда оно даже должно быть возможно прямо во время работыприложения.• Поддержка различных стандартов пользовательского интерфейса и его переносмежду платформами не должны влиять на код, связанный с методами работы сданными и структурой данных приложения.Решение.

Выделяется три набора компонентов. Первый набор — данные, модель данныхили просто модель (model) — соответствует структуре данных предметной области, вкоторой работает приложение. Обязанности этих компонентов: представлять в системеданные и базовые операции над ними. Компоненты второго набора — представления (view)— соответствуют различным способам представления данных в пользовательскоминтерфейсе. Для одних и тех же данных может иметься несколько представлений. Каждомукомпоненту представления соответствует один компонент из третьего набора, обработчик(controller) — компонент, осуществляющий обработку действий пользователей. Такойкомпонент получает команды, чаще всего нажатия клавиш и нажатия кнопок мыши вобластях, соответствующих визуальным элементам управления — кнопкам, элементамменю и пр.

Эти команды он преобразует в действия над данными. В результате каждогодействия требуется обновить все представления всех данных, которые подверглисьизменениям.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. Сценарий обработки действия пользователя.Компонент-обработчик обрабатывает действия пользователя, транслируя их в операции надмоделью или запросы на показ некоторых элементов представлений.

При оповещении обизменениях в модели он соответствующим образом изменяет собственное состояние,например, делая активными или отключая какие-нибудь кнопки и пункты меню.Динамика. У системы два базовых сценария работы — инициализация всех компонентов иобработка некоторого действия пользователя с изменением данных и обновлениемсоответствующих им представлений и обработчиков.ProgramModelViewControllercreatecreateinitialize (model)attachmakeControllercreateinitialize(model, view)attachРисунок 53. Сценарий инициализации системы.Реализация. Основные шаги реализации следующие.• Отделить взаимодействие человека с системой от базовых функций самой системы.Для этого необходимо выделить структуру данных, с которыми система работает, инабор необходимых для функционирования системы операций над ними.• Реализовать механизм передачи изменений.

Для этого можно воспользоватьсяобразцом проектирования Подписчик (иначе называемым Наблюдатель, Observer).• Спроектировать и реализовать необходимые представления.• Спроектировать и реализовать необходимые обработчики действий пользователя.• Спроектировать и реализовать связь между обработчиком и представлением.Обычно представление должно инициализировать соответствующий обработчик.Для этого можно, например, использовать образец проектирования Методпорождения (Factory Method).• Реализовать построение системы из компонентов и инициализацию компонентов.В качестве дополнительных аспектов реализации необходимо рассмотреть следующие.• Динамические представления, создаваемые во время работы приложения.• Подключаемые элементы управления, которые могут быть включены во времяработы приложения.

Например, переключение из режима «новичок» в режим«эксперт».• Инфраструктура и иерархия представлений и обработчиков.Часто имеется готовая библиотека таких компонентов, на основе которых нужностроить собственные представления и обработчики. Эту задачу нужно решать сучетом семантики и возможностей библиотечных компонентов и связей междуними.Кроме того, одни представления могут визуально включать другие, а такжеэлементы управления, с которыми связаны обработчики. Эта визуальная связь частодолжна быть поддержана, например, возможностью переключения фокусапользовательского ввода между отдельными элементами.Необходимо внимательно спроектировать (насколько это возможно, с учетомограничений платформы и библиотек визуальных компонентов) стратегииобработки событий, особенно таких, в которых могут быть одновременнозаинтересованы несколько компонентов, присутствующих на экране.• Возможно, потребуется сделать систему еще более переносимой за счет отделенияее компонентов от конкретных библиотек и платформ.

Для этого нужно разработатьсобственный набор абстрактных визуальных компонентов.Следствия применения образца.Достоинства.• Возможность иметь несколько представлений одних данных, обновляемых порезультатам воздействий пользователя на одно из них. Все такие представлениясинхронизированы, их показания соответствуют друг другу.• Поддержка подключаемых и динамически изменяемых представлений иобработчиков.• Возможность изменения стилей пользовательского интерфейса во время работы.• Возможность построения каркаса (библиотек визуальных компонентов) дляразработки многих интерактивных приложений.Недостатки.• Возрастание сложности разработки.• Потери в производительности из-за необходимости обработки запросовпользователей сначала в обработчиках, затем в моделях, а затем во всехобновляемых компонентах.• Если не оптимизировать производимые обновления аккуратно, чаще всего в ходеработы происходит много ненужных вызовов операций, обновляющихпредставления и обработчики.• Представления и обработчики связаны очень тесно, из-за чего эти компонентыпочти никогда нельзя переиспользовать по отдельности.• И представления, и обработчики достаточно тяжело использовать безсоответствующей им модели.• Представления и обработчики наверняка потребуют изменений при их переносе надругую платформу или в другую библиотеку элементов графического интерфейсапользователя.• Данный образец тяжело использовать в большинстве средств разработки GUI,поскольку они чаще всего определяют собственные стратегии обработки событий истандартные обработчики для многих событий, например, для нажатия правойкнопки мыши.Примеры.

Впервые этот архитектурный стиль был использован при проектированиибиблиотеки разработки пользовательского интерфейса для языка Smalltalk [1]. С тех порсоздатели множества подобных каркасов и библиотек используют те же принципы.Еще один пример библиотеки для разработки пользовательского интерфейса, построенногона основе данного стиля — библиотека MFC (Microsoft Foundation Classes) от Microsoft. Вней используется более простой вариант стиля — с объединенными представлениями иобработчиками.

Такая схема получила название документ-представление (Document-View):документы соответствуют моделям, представления объединяют функции представлений иобработчиков.Такое объединение часто имеет смысл, поскольку представления и обработчики тесносвязаны и практически не могут использоваться друг без друга. Их разделение наотдельные компоненты должно обосновываться серьезными причинами.Последний пример использования этого стиля — архитектура современных Webприложений, т.е. бизнес-приложений с пользовательским интерфейсом на основе HTML исвязью между отдельными элементами, построенной на базе основных протоколовИнтернет.

В ней роль модели играют компоненты, реализующие бизнес-логику и хранениеданных, а роль представлений и обработчиков исполняется HTML-страничками и HTMLформами, статичными или динамически генерируемыми. Далее в этом курсе построениетаких приложений будет рассматриваться более детально, поэтому образец «данныепредставление-обработка» имеет большое значение для дальнейшего изложения.Образцы проектированияОбразцы проектирования в узком смысле являются типовыми проектными решениями,позволяющими удовлетворить часто встречающиеся требования к гибкости приложений иреализовать возможности их расширения за счет специальных форм организации классов и ихсвязей.Далее мы в деталях рассмотрим образец проектирования «подписчик».

О другом примере,«адаптере», было рассказано в начале предыдущей лекции.ПодписчикНазвание. Подписчик (subscriber) или подписчик-издатель (publisher-subscriber). Известентакже под названиями «наблюдатель» (observer), «слушатель» (listener) или «подчиненные»(dependents).Назначение. Реализация системы, в которой нужно поддерживать согласованнымисостояния большого числа объектов.