- •5. Архитектурные особенности проектирования и разработки Веб-приложений
- •5.1. Архитектура информационных систем
- •5.1.1. Общие сведения
- •5.1.2. Централизованная архитектура
- •5.1.3. Архитектура "файл-сервер"
- •5.1.4. Архитектура "клиент-сервер"
- •5.1.5. Многоуровневый "клиент-сервер"
- •5.1.6. Архитектура распределенных систем
- •5.1.7. Архитектура Веб-приложений
- •5.1.8. Сервис-ориентированная архитектура
- •5.1.9. Ключевые термины
- •5.2. Шаблоны проектирования
- •5.2.1. Общие сведения
- •5.2.2. Обзор паттернов
- •5.2.2.1. Паттерны проектирования классов/объектов
- •5.2.2.1.1. Структурные паттерны (Structural)
- •5.2.2.1.2. Паттерны проектирования поведения (Behavioral)
- •5.2.2.1.3. Порождающие паттерны проектирования
- •5.2.2.2. Архитектурные системные паттерны
- •5.2.2.2.1. Структурные паттерны
- •5.2.2.2.2. Паттерны управления
- •5.2.2.2.3. Паттерны, предназначенные для представления данных в Web
- •5.2.2.3. Паттерны интеграции корпоративных информационных систем
- •5.3.2. Ключевые термины
- •5.4. Краткие итоги
5.2.2. Обзор паттернов
5.2.2.1. Паттерны проектирования классов/объектов
5.2.2.1.1. Структурные паттерны (Structural)
К структурным паттернам относятся [25]:
Адаптер (Adapter) – GoF;
Декоратор (Decorator) или Оболочка (Wrapper) – GoF;
Заместитель (Proxy) или Суррогат (Surrogate) – GoF;
Информационный эксперт (Information Expert)- GRASP;
Компоновщик (Composite) – GoF;
Мост (Bridge), Handle (описатель) или Тело (Body) – GoF;
Низкая связанность (Low Coupling) – GRASP;
Приспособленец (Flyweight) – GoF;
Устойчивый к изменениям (Protected Variations) – GRASP;
Фасад (Facade) – GoF.
Приведем примеры 2-х их данных паттернов (табл. 5.1) [25].
|
Таблица 5.1. Примеры структурных паттернов классов/объектов | |
|
Компоновщик (Composite) – GoF | |
|
Проблема |
Как обрабатывать группу или композицию структур объектов одновременно? |
|
Решение |
Определить классы для композитных и атомарных объектов таким образом, чтобы они реализовывали один и тот же интерфейс.
|
|
Фасад (Facade) – GoF | |
|
Проблема |
Как обеспечить унифицированный интерфейс с набором разрозненных реализаций или интерфейсов, например, с подсистемой, если нежелательно высокое связывание с этой подсистемой или реализация подсистемы может измениться? |
|
Решение |
Определить одну точку взаимодействия с подсистемой – фасадный объект, обеспечивающий общий интерфейс с подсистемой и возложить на него обязанность по взаимодействию с ее компонентами. Фасад – это внешний объект, обеспечивающий единственную точку входа для служб подсистемы. Реализация других компонентов подсистемы закрыта и не видна внешним компонентам. Фасадный объект обеспечивает реализацию паттерна "Устойчивый к изменениям" с точки зрения защиты от изменений в реализации подсистемы.
|
5.2.2.1.2. Паттерны проектирования поведения (Behavioral)
К поведенческим паттернам относятся [25]:
Интерпретатор (Interpreter ) – GoF;
Итератор (Iterator) или Курсор (Cursor) – GoF;
Команда (Command), Действие (Action) или Транзакция (Транзакция) – GoF;
Наблюдатель (Observer), Опубликовать – подписаться (Publish – Subscribe) или Delegation Event Model – GoF;
Не разговаривайте с неизвестными (Don't talk to strangers) – GRASP;
Посетитель (Visitor) – GoF;
Посредник (Mediator) – GoF;
Состояние (State) – GoF;
Стратегия (Strategy) – GoF;
Хранитель (Memento) – GoF;
Цепочка обязанностей (Chain of Responsibility) – GoF;
Шаблонный метод (Template Method) – GoF;
Высокое зацепление (High Cohesion) – GRASP;
Контроллер (Controller) – GRASP;
Полиморфизм (Polymorphism) – GRASP;
Искусственный (Pure Fabrication) – GRASP;
Перенаправление (Indirection) – GRASP.
Приведем примеры 3-х их данных паттернов (табл. 5.2) [25].
|
Таблица 5.2. Примеры поведенческих паттернов классов/объектов | |
|
Итератор (Iterator) или Курсор (Cursor) – GoF | |
|
Проблема |
Составной объект, например, список, должен предоставлять доступ к своим элементам (объектам), не раскрывая их внутреннюю структуру, причем перебирать список требуется по-разному в зависимости от задачи. |
|
Решение |
Создается класс "Итератор", который определяет интерфейс для доступа и перебора элементов, "КонкретныйИтератор" реализует интерфейс класса "Итератор" и следит за текущей позицией при обходе "Агрегата". "Агрегат" определяет интерфейс для создания объекта – итератора. "КонкретныйАгрегат" реализует интерфейс создания итератора и возвращает экземпляр класса "КонкретныйИтератор", "КонкретныйИтератор" отслеживает текущий объект в агрегате и может вычислить следующий объект при переборе. Данный паттерн поддерживает различные способы перебора агрегата, одновременно могут быть активны несколько переборов.
|
|
Посетитель (Visitor) – GoF | |
|
Проблема |
Над каждым объектом некоторой структуры выполняется операция. Определить новую операцию, не изменяя классы объектов. |
|
Решение |
Клиент, использующий данный паттерн, должен создать объект класса "КонкретныйПосетитель", а затем посетить каждый элемент структуры. "Посетитель" объявляет операцию "Посетить" для каждого класса "КонкретныйЭлемент" (имя и сигнатура данной операции идентифицируют класс, элемент которого посещает "Посетитель" – то есть, посетитель может обращаться к элементу напрямую). "КонкретныйПосетитель" реализует все операции, объявленные в классе "Посетитель". Каждая операция реализует фрагмент алгоритма, определенного для класса соответствующего объекта в структуре. Класс "КонкретныйПосетитель" предоставляет контекст для этого алгоритма и сохраняет его локальное состояние. "Элемент" определяет операцию "Принять", которая принимает "Посетителя" в качестве аргумента, "КонкретныйЭлемент" реализует операцию "Принять", которая принимает "Посетителя" в качестве аргумента. "СтруктураОбьекта" может перечислить свои аргументы и предоставить посетителю высокоуровневый интерфейс для посещения своих элементов. Данный паттерн логично использовать, если в структуре присутствуют объекты многих классов с различными интерфейсами, и необходимо выполнить над ними операции, зависящие от конкретных классов, или если классы, устанавливающие структуру объектов, изменяются редко, но новые операции над этой структурой добавляются часто. Данный паттерн упрощается добавление новых операций, объединяет родственные операции в классе "Посетитель". В данном паттерне затруднено добавление новых классов "КонкретныйЭлемент", поскольку требуется объявление новой абстрактной операции в классе "Посетитель".
|
|
Состояние (State) – GoF | |
|
Проблема |
Варьировать поведение объекта в зависимости от его внутреннего состояния |
|
Решение |
Класс "Контекст" делегирует зависящие от состояния запросы текущему объекту "КонкретноеСостояние" (хранит экземпляр подкласса "КонкретноеСостояние", которым определяется текущее состояние), и определяет интерфейс, представляющий интерес для клиентов. "КонкретноеСостояние" реализует поведение, ассоциированное с неким состоянием объекта "Контекст". "Состояние" определяет интерфейс для инкапсуляции поведения, ассоциированного с конкретным экземпляром "Контекста". Данный паттерн локализует зависящее от состояния поведение и делит его на части, соответствующие состояниям, переходы между состояниями становятся явными.
|





