- •1. Введение
- •2. Принцип классификации паттернов проектирования
- •3. Паттерны проектирования классов/обьектов
- •3.1 Структурные паттерны проектирования классов/обьектов
- •3.1.1 Адаптер (Adapter) - GoF
- •3.1.2 Декоратор (Decorator) или Оболочка (Wrapper) - GoF
- •3.1.3 Заместитель (Proxy) или Суррогат (Surrogate) - GoF
- •3.1.6 Мост (Bridge), Handle (описатель) или Тело (Body) - GoF
- •3.1.4 Информационный эксперт (Information Expert)- grasp
- •3.1.5 Компоновщик (Composite) - GoF
- •3.1.7 Низкая связанность (Low Coupling) - grasp
- •3.1.8 Приспособленец (Flyweight) - GoF
- •3.1.9 Устойчивый к изменениям (Protected Variations) - grasp
- •3.1.10 Фасад (Facade) - GoF
- •3.2 Паттерны проектирования поведения классов/обьектов
- •3.2.1 Интерпретатор (Interpreter ) - GoF
- •3.2.2 Итератор (Iterator) или Курсор (Cursor) - GoF
- •3.2.3 Команда (Command), Действие (Action) или Транзакция (Транзакция) - GoF
- •3.2.4 Наблюдатель (Observer), Опубликовать - подписаться (Publish - Subscribe) или Delegation Event Model - GoF
- •3.3 Порождающие паттерны проектирования
- •4 Архитектурные системные паттерны
- •4.1 Структурные паттерны
- •4.2 Паттерны управления
- •4.2.1 Паттерны централизованного управления
- •4.2.2 Паттерны управления, основанные на событиях
- •4.2.3 Паттерны, обеспечивающие взаимодействие с базой данных
- •5 Паттерны интеграции корпоративных информационных систем
- •5.1 Структурные паттерны интеграции
- •5.2 Паттерны по методу интеграции
- •5.3 Паттерны интеграции по типу обмена данными
- •6 Заключение
- •7 Приложение: словарь терминов
- •7.1 Общие термины
- •7.2 Термины паттернов проектирования объектов
- •7.3 Термины архитектурных системных паттернов
- •7.4 Термины паттернов интеграции
3.1.7 Низкая связанность (Low Coupling) - grasp
Проблема |
Обеспечить низкую связанность при создании экземпляра класса и связывании его с другим классом. |
Решение |
Распределить обязанности между объектами так, чтобы степень связанности оставалась низкой. |
Пример |
Необходимо создать экземпляр класса "Платеж". В предметной области регистрация объекта "Платеж" выполняется объектом "Регистрация" (ведется рестр). Ниже приводятся 2 способа создания экземпляра класса "Платеж". Верхний рисунок - с использованием паттерна "Создатель", нижний - с использованием "Низкая связанность". Последний способ обеспечивает более низкую степень связывания.
|
3.1.8 Приспособленец (Flyweight) - GoF
Проблема |
Необходимо обеспечить поддержку множества мелких обьектов. |
Рекомендации |
Приспособленцы моделируют сущности, число которых слишком велико для представления объектами. Имеет смысл использовать данный паттерн если одновременно выполняются следующие условия:
|
Решение |
Создать разделяемый объект, который можно использовать одновременно в нескольких контекстах, причем, в каждом контексте он выглядит как независимый объект (неотличим от экземпляра, который не разделяется). "Приспособленец" объявляет интерфейс, с помощью которого приспособленцы могут получить внешнее состояние или как-то воздействовать на него, "КонкретныйПриспособленец" реализует интерфейс класса "Приспособленец" и добавляет при необходимости внутреннее состояние. Внутреннее состояние хранится в объекте "КонкретныйПриспособленец", в то время как внешнее состояние хранится или вычисляется "Клиентами" ("Клиент" передает его "Приспособленцу" при вызове операций). Объект класса "КонкретныйПриспособленец" должен быть разделяемым. Любое сохраняемое им состояние должно быть внутренним, то есть независимым от контекста, "ПриспособленецФабрика" - создает объекты - "Приспособленцы" (или предоставляет существующий экземпляр) и управляет ими. "НеразделяемыйКонкретныйПриспособленец" - не все подклассы "Приспособленца" обязательно должны быть разделяемыми. "Клиент" - хранит ссылки на одного или нескольких "Приспособленцев", вычисляет и хранит внешнее состояние "Приспособленцев".
|
Преимущества |
Вследствие уменьшения общего числа экземпляров и вынесения состояния экономится память. |
3.1.9 Устойчивый к изменениям (Protected Variations) - grasp
Проблема |
Как спроектировать систему так, чтобы изменение одних ее элементов не влияло на другие? |
Решение |
Идентифицировать точки возможных изменений или неустойчивости и распределить обязанности таким образом, чтобы обеспечить устойчивую работу системы. |
Пример |
Паттерн проектирования "Полиморфизм", см. 3.2.15 является хорошей иллюстрацией данного метода. В данном случае точкой вариации или неустойчивости являются интерфейсы внешних систем. При добавлении интерфейса "IНалоговаяСистемаАдаптер" на основе принципа полиморфизма получается, что внутренние объекты смогут взаимодействовать с устойчивым интерфейсом, а детали взаимодействия с внешними системами будут скрыты в конкретных реализациях адаптеров. |
