Другие типы паттернов

ü Model View Controller (MVC)

ü Carrier Rider Mapper, предоставление доступа к хранимой информации

ü аналитические паттерны

ü коммуникационные паттерны

ü организационные паттерны

ü «анти-паттерны» (Anti-Design-Patterns)

В сфере разработки программных систем наибольшее применение получили паттерны проектирования GoF, некоторые из них реализованы в популярных средах программирования.

Паттерны проектирования могут быть представлены в наглядной форме с помощью обозначений языка UML.

Паттерн проектирования в контексте языка UML представляет собой параметризованную кооперацию вместе с описанием базовых принципов ее использования.

При изображении паттерна используется обозначение параметризованной кооперации языка UML (рис. 3.1), которая обозначается пунктирным эллипсом. В правый верхний угол эллипса встроен пунктирный прямоугольник, в котором перечислены параметры кооперации, которая представляет тот или иной паттерн.

Рис. 3.1. Изображение паттерна в форме параметризованной кооперации

В последующем параметры паттерна могут быть заменены различными классами, чтобы получить реализацию паттерна в рамках конкретной кооперации. Эти параметры специфицируют используемые классы в форме ролей классов в рассматриваемой подсистеме. При связывании или реализации паттерна любая линия помечается именем параметра паттерна, которое является именем роли соответствующей ассоциации.

Кроме диаграммам кооперации особенности реализации отдельных паттернов представляются с помощью диаграмм последовательности.

Паттерны проектирования GoF:

ü Abstract Factory – Абстрактная фабрика – предоставляет интерфейс для создания множества связанных между собой или независимых объектов, конкретные классы которых неизвестны.

ü Adapter (синоним: Wrapper) – Адаптер (Обертка) – преобразует существующий интерфейс класса в другой интерфейс, который понятен клиентам. При этом обеспечивает совместную работу классов, невозможную без данного паттерна из-за несовместимости интерфейсов.

ü Bridge – Мост – отделяет абстракцию класса от его реализации, благодаря чему появляется возможность независимо изменять то и другое.

ü Builder – Строитель – отделяет создание сложного объекта от его представления, позволяя использовать один и тот же процесс разработки для создания различных представлений.

ü Chain of Responsibility – Цепочка обязанностей – позволяет избежать жесткой зависимости отправителя запроса от его получателя, при этом объекты-получатели связываются в цепочку, а запрос передается по цепочке, пока какой-то объект его не обработает.

ü Command – Команда – инкапсулирует запрос в виде объекта, обеспечивая параметризацию клиентов типом запроса, установление очередности запросов, протоколирование запросов и отмену выполнения операций.

ü Composite – Компоновщик – группирует объекты в иерархические структуры для представления отношений типа "часть-целое", что позволяет клиентам работать с единичными объектами так же, как с группами объектов.

ü Decorator – Декоратор – применяется для расширения имеющейся функциональности и является альтернативой порождению подклассов на основе динамического назначения объектам новых операций.

ü Facade – Фасад – предоставляет единый интерфейс к множеству операций или интерфейсов в системе на основе унифицированного интерфейса для облегчения работы с системой.

ü Factory Method – Фабричный метод – определяет интерфейс для разработки объектов, при этом объекты данного класса могут быть созданы его подклассами.

ü Flyweight – Приспособленец – использует принцип разделения для эффективной поддержки большого числа мелких объектов.

ü Interpreter – Интерпретатор – для заданного языка определяет представление его грамматики на основе интерпретатора предложений языка, использующего это представление.

ü Iterator – Итератор – дает возможность последовательно перебрать все элементы составного объекта, не раскрывая его внутреннего представления.

ü Mediator – Посредник – определяет объект, в котором инкапсулировано знание о том, как взаимодействуют объекты из некоторого множества. Способствует уменьшению числа связей между объектами, позволяя им работать без явных ссылок друг на друга и независимо изменять схему взаимодействия.

ü Memento – Хранитель – дает возможность получить и сохранить во внешней памяти внутреннее состояние объекта, чтобы позже объект можно было восстановить точно в таком же состоянии, не нарушая принципа инкапсуляции.

ü Observer – Наблюдатель – специфицирует зависимость типа "один ко многим" между различными объектами, так что при изменении состояния одного объекта все зависящие от него получают извещение и автоматически обновляются.

ü Prototype – Прототип – описывает виды создаваемых объектов с помощью прототипа, что позволяет создавать новые объекты путем копирования этого прототипа.

ü Proxy – Заместитель – подменяет выбранный объект другим объектом для управления контроля доступа к исходному объекту.

ü Singleton – Одиночка – для выбранного класса обеспечивает выполнение требования единственности экземпляра и предоставления к нему полного доступа.

ü State – Состояние – позволяет выбранному объекту варьировать свое поведение при изменении внутреннего состояния. При этом создается впечатление, что изменился класс объекта.

ü Strategy – Стратегия – определяет множество алгоритмов, инкапсулируя их все и позволяя подставлять один вместо другого. При этом можно изменять алгоритм независимо от клиента, который им пользуется.

ü Template Method – Шаблонный метод – определяет структуру алгоритма, перераспределяя ответственность за некоторые его шаги на подклассы. При этом подклассы могут переопределять шаги алгоритма, не меняя его общей структуры.

ü Visitor – Посетитель – позволяет определить новую операцию, не меняя описаний классов, у объектов которых она вызывается.

Паттерн Facade

Паттерн Facade предназначен для замены нескольких разнотипных интерфейсов доступа к определенной подсистеме некоторым унифицированным интерфейсом, что существенно упрощает использование рассматриваемой подсистемы. Общее представление приведено на рис. 3.2 с помощью диаграммы параметризованной кооперации.

Рис. 3.2. Общее представление паттерна проектирования Facade

Параметризованная кооперация содержит параметры:

ü класс Facade,

ü интерфейс IFacade,

ü интерфейсы IСoncreteClass,

ü конкретные классы ConcreteClass, в которых реализованы интерфейсы IConcreteClass.

Пунктирная линия со стрелкой в форме треугольника служит для обозначения отношения реализации.

При решении конкретных задач проектирования данный паттерн может быть конкретизирован. В этом случае вместо параметров изображенной кооперации должны быть указаны классы, предназначенные для решения отдельных задач.

Пример: использование паттерна Facade для выполнения операций по заданию и считыванию адресов из базы данных сотрудников. Фрагмент соответствующей диаграммы классов содержит 2 класса: Адрес и интерфейс к операциям этого класса IАдрес (рис. 3.3).

При задании адреса нового сотрудника необходимо обратиться к этому интерфейсу и последовательно выполнить операции: задатьУлицу(), задатьДом(), задатьКорпус(), задатьКвартиру(), используя в качестве аргумента идентификационный номер нового сотрудника.

Для получения информации об адресе сотрудника, необходимо также обратиться к этому интерфейсу и последовательно выполнить операции: прочитатьУлицу(), прочитатьДом(), прочитатьКорпус(), прочитатьКвартиру(), используя в качестве аргумента идентификационный номер интересуемого сотрудника.

Рис. 3.3. Фрагмент диаграммы классов до применения паттерна Facade

Очевидно, отслеживать при каждом обращении правильность выполнения этих последовательностей операций неудобно. С этой целью к данному фрагменту следует добавить еще один интерфейс, реализацию паттерна Facade для рассматриваемой ситуации. Соответствующий фрагмент модифицированной диаграммы классов будет содержать 4 класса (рис. 3.4), изображенные таким образом, чтобы иллюстрировать реализацию параметрической кооперации (рис. 3.2).

Рис. 3.4. Конкретная реализация паттерна проектирования Facade

При задании адреса нового сотрудника в этом случае достаточно обратиться к интерфейсу IФасад и выполнить единственную операцию: задатьАдрес(), используя в качестве аргумента идентификационный номер нового сотрудника.

Для получения информации об адресе сотрудника также достаточно обратиться к этому интерфейсу и выполнить единственную операцию: прочитатьАдрес(), используя в качестве аргумента идентификационный номер интересуемого сотрудника.

Реализацию данных операций следует предусмотреть в классе Facade. Взаимодействие объектов этих классов может быть представлено с помощью диаграммы последовательности (рис. 3.5).

Рис. 3.5. Диаграмма последовательности для операции задания адреса

Аналогичная диаграмма последовательности может быть построена для выполнения операции по чтению адреса.

Использование паттерна Facade обеспечивает для клиента не только простоту доступа к информации об адресах, но и независимость представления объектов класса Адрес от запросов клиентов. При изменении формата представления информации или смене соответствующей базы данных потребуется внести изменения только в реализацию операций класса Facade.

Паттерн Observer

Паттерн Observer предназначен для контроля изменений состояния объекта и передачи информации об изменении этого состояния множеству клиентов.

В общем случае паттерн Observer может быть изображен в виде параметризованной кооперации (рис. 3.6).

Рис. 3.6. Общее представление паттерна проектирования Observer

Параметризованная кооперация содержит 4 параметра:

ü абстрактный класс Subject (Субъект),

ü класс ConcreteSubject (Конкретный Субъект),

ü абстрактный класс Observer (Наблюдатель);

ü класс ConcreteObserver (Конкретный Наблюдатель).

Сплошная линия со стрелкой в форме треугольника служит для обозначения отношения обобщения классов.

При решении конкретных задач проектирования данный паттерн также может быть конкретизирован. В этом случае вместо параметров изображенной кооперации должны быть указаны классы, предназначенные для решения отдельных задач.

Пример: использование паттерна Observer для отслеживания изменений в таблице БД и отражении этих изменений на диаграммах.

Для определенности можно использовать таблицу БД MS Access и две диаграммы – круговую и столбиковую. Фрагмент соответствующей диаграммы классов содержит 5 классов (рис. 3.7).

Рис. 3.7. Конкретная реализация паттерна проектирования Observer

В этом случае за субъектом ТаблицаMSAccess может "следить" произвольное число наблюдателей, причем их добавление или удаление не влияет на представление информации в БД. Класс ТаблицаMSAccess реализует операции по отслеживанию изменений в соответствующей таблице, и при их наличии сразу информирует абстрактного наблюдателя. Тот в свою очередь вызывает операции по перерисовке соответствующих диаграмм у конкретных наблюдателей, в качестве которых выступают классы КруговаяДиаграмма и СтолбиковаяДиаграмма.

Использование паттерна Observer не только упрощает взаимодействие между объектами соответствующих классов, но и позволяет вносить изменения в реализацию операций классов субъекта и наблюдателей независимо друг от друга. При этом процесс добавления или удаления наблюдателей никак не влияет на особенности реализации класса субъекта.

Контрольные вопросы

1. Для чего предназначены паттерны проектирования?

2. На какие группы можно разделить паттерны проектирования?

3. Какие паттерны проектирования получили наибольшее применение?

4. Для решения какой задачи предназначен паттерн Facade?

5. Для решения какой задачи предназначен паттерн Observer?

3.3. Архитектурные паттерны

Наиболее известными архитектурными паттернами являются паттерны GRASP.

GRASP (General Responsibility Assignment Software Patterns) – общие паттерны распределения обязанностей в программных системах (обязанности описывают поведение объекта).

Паттерн Expert

Решение: назначить обязанность информационному эксперту – классу, у которого имеется информация, требуемая для выполнения обязанности.

Выполняется распределение обязанностей между классами.

Принцип: обязанности связываются с тем объектом, который имеет информацию, необходимую для их выполнения.

Пример: В приложении системы розничной торговли некоторому классу необходимо знать общую сумму продажи.

Согласно паттерну Expert нужно определить, объекты каких классов содержат информацию, необходимую для вычисления общей суммы. Фрагмент концептуальной модели приведен на рис. 3.8.

Рис. 3.8. Фрагмент концептуальной модели

Необходимо узнать стоимость всех проданных товаров SalesLineItem и просуммировать эти промежуточные суммы. Такой информацией обладает экземпляр объекта Sale. С точки зрения паттерна Expert объект Sale подходит для выполнения этой обязанности, т.е. является информационным экспертом.

Для вычисления промежуточной суммы элементов продажи необходимы значения SalesLineItem.quantity и ProductSpecification.price. Объекту SalesLineItem известно количество товара и связанный с ним объект ProductSpecification. В соответствии с паттерном Expert промежуточную сумму должен вычислять объект SalesLineItem, он и будет являться информационным экспертом. Это означает, что объект Sale должен передать сообщения subtotal() каждому объекту SalesLineItem, а затем просуммировать полученные результаты.

Для выполнения обязанности, связанной со знанием и предоставлением промежуточной суммы, объекту SalesLineItem должна быть известна стоимость товара. В данном случае информационным экспертом будет объект ProductSpecification.

Диаграмма кооперации для вычисления общей суммы приведена на рис. 3.9.

Таким образом, для выполнения обязанности знать и предоставлять общую сумму продажи были присвоены следующие обязанности:

ü Классу Sale обязанность total() – знание промежуточной суммы для данного товара;

ü Классу SalesLineItem обязанность subtotal() – знание общей суммы продажи;

ü Классу ProductSpecification обязанность price() – знание стоимости товара.

Рис. 3.9. Диаграмма кооперации для вычисления общей суммы

Паттерн Creator

Решение: Назначить классу B обязанность создавать экземпляры класса A, если выполняется одно из условий:

ü Класс B агрегирует объекты класса A;

ü Класс B содержит объекты класса A;

ü Класс B записывает экземпляры объектов класса A;

ü Класс B активно использует объекты класса A;

ü Класс B обладает данными инициализации, которые будут передаваться объектам класса A при его создании (при создании объектов А класс В является экспертом).

Класс В – создатель (creator) объектов класса А.

Если выполняется несколько из этих условий, то лучше использовать класс В, агрегирующий или содержащий класс А.

Выполняется распределение обязанностей, связанных с процессом создания объектов.

Пример: Чтобы найти класс, отвечающий за создание нового экземпляра объекта SalesLineItem в соответствии с паттерном Creator, необходимо найти класс, агрегирующий, содержащий и т.д. экземпляры объектов SalesLineItem. Рассмотрим концептуальную модель, представленную на рис. 3.8.

Так как объект Sale содержит (фактически – агрегирует) несколько объектов SalesLineItem, то его можно считать кандидатом для выполнения обязанности, связанной с созданием экземпляров объектов SalesLineItem. Это приводит к необходимости создания взаимодействия объектов, представленного на рис. 3.10.

Рис. 3.10. Создание экземпляров объекта SalesLineItem

Необходимо, чтобы в объекте Sale был определен метод makeLineItem.

Предположим, что при создании экземпляра объекта Payment нужно выполнить инициализацию с использованием общей суммы, содержащейся в объекте Sale. Так как объекту Sale эта сумма известна, то он и является кандидатом на выполнение обязанности, связанной с созданием экземпляра объекта Payment.

Паттерн Low Coupling

Решение: распределить обязанности таким образом, чтобы степень сцепления оставалась низкой.

Высокое сцепление приводит к возникновению проблем:

ü Изменения в классах приводят к локальным изменениям в других классах;

ü Затрудняется понимание каждого класса в отдельности;

ü Усложняется повторное использование классов.

Паттерн Low Coupling подразумевает такое распределение обязанностей, которое не влечет за собой чрезмерное повышение степени сцепления. Данный паттерн не рассматривается отдельно от других принципов, сформулированных в паттернах Expert и High Cohesion.

Пример: Пусть имеется три класса для терминального приложения системы розничной торговли: Sale (Продажа), POST (Торговая точка POST), Payment (Платеж). Предположим, что необходимо создать экземпляр класса Payment и связать его с объектом Sale. Так как в реальной предметной области регистрация объекта Payment выполняется объектом POST, то в соответствии с паттерном Creator объект POST является кандидатом для создания объекта Payment. Затем экземпляр объекта POST должен передать сообщение addPayment объекту Sale, указав в качестве параметра новый объект Payment (рис. 3.11). При таком распределении обязанностей предполагается, что класс POST связывается с данными класса Payment.

Рис. 3.11. Создание нового объекта Payment объектом POST

Альтернативный способ создания объекта Payment приведен на рис. 3.12.

Рис. 3.12. Создание нового объекта Payment объектом Sale

В обоих случаях предполагается, что в конечном итоге объекту Sale должно быть известно о существовании объекта Payment. С точки зрения числа связей между объектами второй из способов предпочтительнее, так как степень сцепления объектов в данном случае ниже (в первом случае добавляется новая связь).

Паттерн High Cohesion

Решение: распределение обязанностей, поддерживающее высокую степень связности.

Низкая степень связности приводит к проблемам:

ü Трудность понимания;

ü Сложность повторного использования;

ü Сложность поддержки;

ü Ненадежность, постоянная подверженность изменениям.

Данный паттерн не рассматривается отдельно от других принципов, сформулированных в паттернах Expert и Low Coupling.

Пример: Рассмотрим тот же пример, что и в случае с Low Coupling.

Предположим, что необходимо создать экземпляр класса Payment и связать его с текущей продажей. Так как в реальной предметной области сведения о платежах записываются в системе POST, то в соответствии с паттерном Creator объект POST является кандидатом для создания объекта Payment. Тогда экземпляр объекта POST сможет отправить сообщение addPayment объекту Sale, передавая в качестве параметра новый экземпляр объекта Payment (рис. 3.11). При таком распределении обязанностей платежи выполняет объект POST, т.е. он частично несет ответственность за выполнение системной операции addPayment. В данном обособленном примере это приемлемо, но если далее возлагать на класс POST обязанности по выполнению все новых и новых обязанностей, связанных с другими системными операциями, то этот класс будет слишком перегружен и будет обладать низкой степенью связности.

В другом варианте распределения обязанностей (рис. 3.12) функция создания экземпляра платежа делегирована объекту Sale. Благодаря чему поддерживается более высокая степень связности объекта POST.

Паттерн Controller

Решение: делегирование обязанностей по обработке системных сообщений классу, удовлетворяющему одному из следующих условий:

ü Класс представляет всю систему в целом (внешний контроллер);

ü Класс представляет всю организацию (внешний контроллер);

ü Класс представляет активный объект из реального мира (например, роль человека), который может участвовать в решении задачи (контроллер роли);

ü Класс представляет искусственный обработчик всех системных событий некоторого варианта использования и обычно называется обработчиком (handler) (контроллер варианта использования). Для всех системных событий в рамках одного варианта использования применяется один и тот же контроллер. Для каждого варианта использования должен быть свой контроллер.

Системное событие – событие высокого уровня, генерируемое внешним исполнителем. Пример системного события – когда кассир нажимает кнопку End Sale, он генерирует системное событие, свидетельствующее о завершении торговой операции.

Контроллер – объект, не относящийся к интерфейсу пользователя и отвечающий за обработку системных событий. Контроллер определяет методы для выполнения системных операций.

В приложении розничной торговли можно выделить несколько системных операций: endSale(), enterItem(), makePayment(). Какой класс можно выбрать в качестве контроллера?

Согласно паттерну Controller возможны следующие варианты:

ü POST (Торговая точка, оснащенная системой POST) – класс, представляющий всю систему в целом;

ü Store (Магазин) – класс, представляющий всю организацию;

ü Cashier (Кассир) – класс, представляющий активный объект из реального мира, который может участвовать в решении задачи;

ü BuyItemHandler – класс, представляющий искусственный обработчик всех системных событий некоторого варианта использования.

Выбор наиболее подходящего контроллера определяется факторами связности и сцепления. Системные операции присваиваются одному или нескольким классам контроллеров, например, POST.

Контрольные вопросы

1. Для чего предназначены архитектурные паттерны?

2. Какие архитектурные паттерны наиболее известны?

3. Для решения какой задачи предназначен паттерн Expert?

4. Для решения какой задачи предназначен паттерн Creator?

5. Для решения каких задач предназначены паттерны Low Coupling и HighCohesion?

6. Для чего используется паттерн Controller?

ЗАКЛЮЧЕНИЕ

Язык UML представляет собой нотацию для визуального моделирования программных систем и бизнес-процессов. В тоже время описание языка UML не содержит сведений относительно того, каким образом и в какой последовательности следует разрабатывать канонические диаграммы при выполнении конкретных проектов. Соответствующая информация относится к области методологии проектирования программных систем. В настоящее время наиболее известны следующие методологии:

ü Rational Unified Process (RUP), разработанная и поддерживаемая компанией IBM Rational Software

ü Microsoft Solutions Framework (MSF), разработанная и поддерживаемая компанией Microsoft

ü Application Lifecycle Management (ALM), разработанная и поддерживаемая компанией Borland

ü Extreme Programming (XP) – экстремальное программирование, поддерживаемое открытым сообществом независимых разработчиков

Литература

1. Леоненков А.В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose. Учебное пособие. - издательство "Интуит", 2006, 320 с.

2. Ларман Крэг Применение UML и шаблонов проектирования: Пер. с англ.: Уч. пос. – М.: Издательский дом «Вильямс», 2001. – 496 с.: ил.

3. С.Орлов Технологии разработки программного обеспечения. Учебное пособие. 2-е изд. – СПб.: Питер, 2003. – 480 с.:ил.

4. Уэнди Боггс, Майкл Боггс UML и Rational Rose^©: Пер.с англ. – М.: Издательство «ЛОРИ», 2000. – 581 с.

5. UML for Java Programmers Robert Cecit Martin Object Mentor Inc. Prentice Hall, Englewood Cliffs, New Jersey 07632, 2002, 236 pp.

6. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. – М.:Мир, 1999. – 191 с., ил.

Поиск по сайту: