Шаблон Controller(контроллер)
Проблема.Кто должен отвечать за обработку входных системных событий?
Системное событие (systemevent) – это событие высокого уровня, генерируемое внешним исполнителем (событие с внешним входом). Системные события связаны с системными операциями (systemoperation), т.е. операциями, выполняемыми системой в ответ на события.
Решение.Делегирование обязанностей по обработке системных сообщений классу, удовлетворяющему одному из следующих условий:
Класс представляет всю систему в целом, устройство или подсистему (внешний контроллер);
Класс представляет сценарий некоторого прецедента, в рамках которого выполняется обработка всех системных событий, и обычно называется Handler, Coordinator или Session (контроллер прецедента или контроллер сеанса);
Для всех системных событий в рамках одного сценария прецедента используется один и тот же класс-контроллер.
Неформально, сеанс – это экземпляр взаимодействия с исполнителем. Сеансы могут иметь произвольную длину, но зачастую организованы в рамках прецедента (сеансы прецедента).
Заметим, что в этот перечень не включаются классы, реализующие окно, аплет, приложение, вид и документ. Такие классы не выполняют задачи, связанные с системными событиями. Они обычно получают сообщения и делегируют их контроллерам.
Контроллер (controller) – это объект, не относящийся к интерфейсу пользователя и отвечающий за обработку системных событий. Контроллер определяет методы для выполнения системных операций.
Большинство систем получает внешние события. Обычно они связаны с графическим интерфейсом пользователя. Кроме того, системе могу передаваться внешние сообщения, например, при обработке телекоммуникационных сигналов или сигналов от датчиков в системах управления.
Во всех случаях при использовании объектно-ориентированного подхода для обработки внешних событий применяются контроллеры. Шаблон Controllerобеспечивает наиболее типичные проектные решения для этого случая. Как видно из рисунка 7.1, контроллер – это своеобразный вид интерфейса между уровнями предметной области и графического представления.
Типичной ошибкой при создании контроллеров является возложение на них слишком большого числа обязанностей. Обычно, контроллер должен лишь делегировать функции другим объектам и координировать их деятельность, а не выполнять эти действия самостоятельно.
Контроллеры делятся на два типа:
Внешний контроллер (facade controller). Представляет всю "систему", устройство или подсистему. Основная идея сводится к выбору некоторого класса, имя которого охватывает все слои приложения. Этот класс обеспечивает главную точку вызова всех служб из интерфейса пользователя и обращения к остальным слоям. Этот класс может представлять физический объект, телекоммуникационный переключатель, всю программную часть системы, или любые другие понятия, выбранные разработчиком для представления системы в целом. Внешние контроллеры удобно использовать в том случае, когда существует лишь несколько системных событий или системные сообщения невозможно перенаправить другим контроллерам, наподобие системы обработки сообщений.
Контроллер прецедента (use case controller). Для каждого прецедента должен существовать отдельный контроллер. Контроллеры прецедентов следует использовать в том случае, когда применение внешнего контроллера приводит к слабой степени зацепления или высокой степени связывания. Контроллер прецедента вводится в том случае, если существующий контроллер слишком "раздувается" при возложении на него дополнительных обязанностей. Контроллеры прецедентов следует применять при наличии большого числа системных событий, распределенных между различными процессами
- «Технологии разработки программного обеспечения»
- Оглавление
- Введение
- Анализ проблемы. Постановка задачи
- Введение
- Описание примера
- Составление списка заинтересованных лиц
- Анкетирование и проведение интервью
- Список потребностей заинтересованных лиц
- Задания
- Контрольные вопросы
- Моделирование объекта автоматизации
- Введение
- Введение в методологиюAris
- Описание инструментаAris. Начало работы
- Построение организационной модели
- Построение диаграммы цепочек добавленного качества
- ПостроениеeEpCмодели
- Описание объектов автоматизации
- Задания
- Контрольные вопросы
- Разработка модели вариантов использования и их спецификаций
- Введение
- Разработка модели вариантов использования
- Модель вариантов использования
- Построение модели вариантов использования
- Спецификация вариантов использования
- Основной поток
- Альтернативные потоки
- Специальные требования
- Пример спецификации варианта использования
- Алгоритм расчёта рейтингов
- Задания
- Пример написания раздела
- Назначение документа
- Наименование системы
- Сведения о заказчике и исполнителе
- Основания для выполнения работ, сроки и финансирование
- Основные понятия, определения и сокращения
- Актуальность разработки системы
- Назначение и цели создания (развития) системы
- Требования к содержимому раздела
- Пример написания раздела
- Характеристики объекта автоматизации
- Требования к содержимому раздела
- Пример написания раздела
- Организация и планирование научно-исследовательской и инновационной деятельности
- Исполнители научно-исследовательских работ
- Учет и отчетность по научно-исследовательским работам
- Требования к системе
- Требования к содержимому раздела
- Пример написания раздела
- Требования к системе в целом
- Требования к структуре и функционированию системы
- Требования к численности и квалификации персонала
- Требования к функциям (задачам)
- Описание вариантов использования
- Состав и содержание работ по созданию системы
- Требования к содержимому раздела
- Пример написания раздела
- Порядок контроля и приемки системы
- Требования к содержимому раздела
- Пример написания раздела
- Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
- Требования к содержимому раздела
- Пример написания раздела
- Создание служб необходимых для функционирования системы
- Функциональные этапы внедрения системы
- Требования к документированию
- Требования к содержимому раздела
- Пример написания раздела
- Паспорт системы
- Общее описание системы
- Руководство администратора
- Руководство пользователя
- Регламент эксплуатации
- Источники разработки
- Правила оформления
- Задание
- Бизнес-логика
- Объектно-реляционное отображение
- Структура бд
- Создание проекта вBorlandDeveloperStudio
- Добавление нового модуля в проект
- Создание классов с помощью диаграммыUml
- Добавление полей
- Добавление свойств
- Добавление процедуры
- Добавление функции
- Создание отношений между классами
- Ассоциация
- Агрегация
- Наследование
- Пример создания классов
- Создание классов и отношений между ними слоя объектно-реляционного отображения
- Создание классов слоя бизнес-логики
- Невизуальные компоненты интерфейса используемые в примере
- TimageList
- TActionManager
- Визуальные компоненты используемые в примере
- TBitBtn
- TdbGrid
- TcomboBox
- TPageControl
- Пример разработки интерфейса
- Главная форма
- Форма редактирования параметров студента
- Форма редактирования книг
- Форма отображения списка книг
- Подключение классов
- Сохранение проекта
- Задание
- Шаблоны проектирования
- Шаблон InformationExpert(информационный эксперт)
- Преимущества
- Шаблон Creator(создатель)
- Преимущества
- Шаблон LowCoupling(слабое связывание)
- Преимущества
- Шаблон HighCohesion(высокое зацепление)
- Преимущества
- Шаблон Controller(контроллер)
- Преимущества
- Применение шаблонаInformationExpert
- Применение шаблонаCreator
- Использование шаблонаHighCohesion
- Применение шаблонаController
- Задание
- Технология eco
- Язык объектных ограничений ocl
- Mdi-контейнеры
- Создание простого mda-приложения
- Основные этапы разработки приложения
- Обзор возможностей Borland Developer Studio 2006 для разработки mda-приложения
- Создание моделиUml
- Создание бд и настройкаEcOкомпонент
- Создание интерфейса
- Связывание интерфейса с моделью
- Создание логики наOcl
- Задания
- Контрольные вопросы
- РазработкаMda-приложения с использованием машин состояний
- Введение
- Автоматы
- Состояния
- Подавтоматы
- Диаграммы состояний
- Создание mda-приложений с использованием машин состояний
- Модификация модели uml
- Создание машины состояний
- Обновление базы данных
- Модификация пользовательского интерфейса
- Связывание интерфейса с моделью
- Применение автоформ
- Расширение пользовательского интерфейса
- Задания
- Контрольные вопросы
- Расширенные возможности разработкиMda-приложений
- СозданиеMda-приложения с расширенными возможностями
- Модификация моделиUml
- Программное добавление объекта
- Программное удаление объекта
- Программное редактирование объекта
- Работа со справочником
- Поиск объектов
- Задания
- Контрольные вопросы
- Заключение
- Библиографический список