Обзор паттернов проектирования

Абстрактная фабрика (Abstract Factory, Factory), др. название Инструментарий (Kit) - GoF

Проблема	Создать семейство взаимосвязанных или взаимозависимых обьектов (не специфицируя их конкретных классов).
Решение	Создать абстрактный класс, в котором объявлен интерфейс для создания конкретных классов.
Пример	Какой класс должен отвечать за создание обьектов - адаптеров при использовании паттерна "Адаптер", см. . Если подобные объекты создаются неким объектом уровня предметной области, то будет нарушен принцип разделения обязанностей.
Преимущества	Изолирует конкретные классы. Поскольку "Абстрактная фабрика" инкапсулирует ответственность за создание классов и сам процесс их создания, то она изолирует клиента от деталей реализации классов. Упрощена замена "Абстрактной фабрики", поскольку она используется в приложении только один раз при инстанцировании.
Недостатки	Интерфейс "Абстрактной фабрики" фиксирует набор обьектов, которые можно создать. Расширение "Абстрактной фабрики" для изготовления новых обьектов часто затруднительно.

Адаптер (Adapter) - GoF

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

Активная запись (Active Record)

Описание

Если предметная область несложная, то логично возложить на каждый класс порцию бизнес - логики.
При использовании этого паттерна объект класса "осведомлен" о том, как взаимодействовать с таблицами базы данных.
Активная запись (Active Record)

АРХИТЕКТУРНЫЕ СИСТЕМНЫЕ ПАТТЕРНЫ

Согласно предложенному принципу классификации паттерны проектирования архитектурные системные паттерны объединены в группы в соответствии с теми задачами, для решения которых они разработаны. Для организации классов или обьектов системы в базовые подструктуры (то есть в подсистемы - соответствующее определение дано в разделе 7.1) используются структурные архитектурные паттерны, см. . С другой стороны, для обеспечения требуемого системного функционала первостепенное значение имеет адекватная организация взаимодействия отдельных архитектурных элементов системы - этой цели служат управления, см. .
В свою очередь, паттерны управления разделены на паттерны централизованного управления, 4.2.1 (то есть паттерны, в которых одна из подсистем полностью отвечает за управление, запускает и завершает работу остальных подсистем) и паттерны управления, подразумевающие децентрализованное реагирование на события, 4.2.2, (согласно этим паттернам на внешние события, определённые в разделе 7.3, отвечает соответствующая подсистема.). Также следует упомянуть, что поскольку проектирование взаимодействия той или иной подсистемы с реляционной базой данных (определенной в разделе 7.3) является неотъемлемой частью разработки корпоративных информационных систем, среди паттернов управления выделена большая группа паттернов, описывающих организацию связи с базой данных, см. .

Цепочка обязанностей (Chain of Responsibility) - GoF

Проблема	Запрос должен быть обработан несколькими объектами.
Рекомендации	Логично использовать данный паттерн, если имеется более одного объекта, способного обработать запрос и обработчик заранее неизвестен (и должен быть найден автоматически) или если весь набор обьектов, которые способны обработать запрос, должен задаваться автоматически.
Решение	Связать объекты - получатели запроса в цепочку и передать запрос вдоль этой цепочки, пока он не будет обработан. "Обработчик" определяет интерфейс для обработки запросов, и, возможно, реализует связь с преемником, "КонкретныйОбработчик" обрабатывает запрос, за который отвечает, имеет доступ к своему преемнику ("КонкретныйОбработчик" направляет запрос к своему преемнику, если не может обработать запрос сам.
Преимущества	Ослабляется связанность (объект не обязан "знать", кто именно обработает его запрос).
Недостатки	Нет гарантий, что запрос будет обработан, поскольку он не имеет явного получателя.

Cохранение сеанса на стороне клиента (Client Session State)

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

Cохранение сеанса на стороне сервера (Server Session State)

Задача	Сохранять сведения о сеансе.
Решение	На клиенте хранится только идентификатор сеанса, а все данные о сеансе хранятся сервером. Для хранения обьектов сеансов на сервере формируется специальная коллекция.
Преимущества	Передается только идентификатор сеанса, а не весь обьем данных о сеансе.
Недостатки	Требуются значительные ресурсы сервера.

Декоратор (Decorator) или Оболочка (Wrapper) - GoF

Проблема	Возложить дополнительные обязанности (прозрачные для клиентов) на отдельный объект, а не на класс в целом.
Рекомендации	Применение нескольких "Декораторов" к одному "Компоненту" позволяет произвольным образом сочетать обязанности, например, одно свойство можно добавить дважды.
Решение	Динамически добавить объекту новые обязанности не прибегая при этом к порождению подклассов (наследованию). "Компонент"определяет интерфейс для обьектов, на которые могут быть динамически возложены дополнительные обязанности, "КонкретныйКомпонент" определяет объект, на который возлагаются дополнительные обязанности, "Декоратор" - хранит ссылку на объект "Компонент" и определяет интерфейс, соответствующий интерфейсу "Компонента". "КонкретныйДекоратор" возлагает дополнительные обязанности на компонент. "Декоратор" переадресует запросы объекту "Компонент".
Преимущества	Большая гибкость, чем у статического наследования: можно добавлять и удалять обязанности во время выполнения программы в то время как при использовании наследования надо было бы создавать новый класс для каждой дополнительной обязанности. Данный паттерн позволяет избежать перегруженных методами классов на верхних уровнях иерархии - новые обязанности можно добавлять по мере необходимости.
Недостатки	"Декоратор" и его "Компонент" не идентичны, и, кроме того, получается что система состоит из большого числа мелких обьектов, которые похожи друг на друга и различаются только способом взаимосвязи а не классом и не значениями своих внутренних переменных - такая система сложна в изучении и отладке.

Диспетчер

Описание	Один системный компонент назначается диспетчером и управляет запуском и завершением других процессов системы и координирует эти процессы. Процессы могут протекать параллельно.
Рекомендации	Применяется в системах, в которых необходимо организовать параллельные процессы, но может использоваться также и для последовательных систем, в которых- управляющая программа вызывает отдельные подсистемы в зависимости от значений некоторых переменных состояния.
Пример	Можно использовать в системах реального времени, где нет чересчур строгих временных ограничений (в так называемых "мягких" системах реального времени).

Единица работы (Unit Of Work)

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

Factory Method или Виртуальный конструктор (Virtual Constructor) - GoF

Проблема	Определить интерфейс для создания объекта, но оставить подклассам решение о том, какой класс инстанцировать, то есть, делегировать инстанцирование подклассам.
Решение	Абстрактный класс "Создатель" объявляет ФабричныйМетод, возвращающий объект типа "Продукт" (абстрактный класс, определяющий интерфейс обьектов, создаваемых фабричным методом). "Создатель также может определить реализацию по умолчанию ФабричногоМетода, который возвращает "КонкретныйПродукт". "КонкретныйСоздатель" замещает ФабричныйМетод, возвращающий объект "КонкретныйПродукт". "Создатель" "полагается" на свои подклассы в определении ФабричногоМетода, возвращающего объект "КонкретныйПродукт".
Преимущества	Избавляет проектировщика от необходимости встраивать в код зависящие от приложения классы.
Недостатки	Возникает дополнительный уровень подклассов.

Файловый обмен

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

Фасад (Facade) - GoF

Проблема

Как обеспечить унифицированный интерфейс с набором разрозненных реализаций или интерфейсов, например, с подсистемой, если нежелательно высокое связывание с этой подсистемой или реализация подсистемы может измениться?

Решение

Определить одну точку взаимодействия с подсистемой - фасадный объект, обеспечивающий общий интерфейс с подсистемой и возложить на него обязанность по взаимодействию с ее компонентами. Фасад - это внешний объект, обеспечивающий единственную точку входа для служб подсистемы. Реализация других компонентов подсистемы закрыта и не видна внешним компонентам. Фасадный объект обеспечивает реализацию паттерна "Устойчивый к изменениям" с точки зрения защиты от изменений в реализации подсистемы., см. п. .

Функционально-центрический (function-centric) подход.

Описание

При функционально-центрическом подходе основным системообразующим фактором являются сервисы - общеупотребительные прикладные и системные функции коллективного доступа, реализованные в виде серверных программ со стандартным API. В виде сервисов реализуются такие функции, как различного вида прикладная обработка, контроль информационной безопасности, служба единого времени, централизованный файловый доступ и т.п. Все сервисы являются интегрированными в том же смысле, что и интегрированные данные в базе данных коллективного доступа, т.е. реализуемые сервисами функции достоверны, непротиворечивы и общедоступны. Концепция интеграции в данном подходе состоит в том, что приложения объединяются в систему вокруг интегрированных сервисов со стандартизованным интерфейсом. Интегрирующей средой является сервер приложений или монитор транзакций со стандартным API. При использовании функционально-центрического подхода приложение декомпозируется на три уровня (взаимодействие с пользователем, прикладная обработка, доступ к данным). Общая архитектура системы является трехзвенной: клиентское приложение - функциональные сервисы - сервер базы данных.

Хранитель (Memento) - GoF

Проблема	Необходимо зафиксировать поведение объекта для реализации, например, механизма отката.
Решение	Зафиксировать и вынести (не нарушая инкапсуляции) за пределы объекта его внутреннее состояние так, чтобы впоследствии можно было восстановить в нем объект. "Хранитель" сохраняет внутреннее состояние объекта "Хозяин" и запрещает доступ к себе всем другим объектам кроме "Хозяина", который имеет доступ ко всем данным для восстановления в прежнем состоянии. "Посыльный" может лишь передавать "Хранителя" другим объектам. "Хозяин" создает "Хранителя", содержащего снимок текущего внутреннего состояния и использует "Хранитель" для восстановления внутреннего состояния. "Посыльный" отвечает за сохранение "Хранителя", при этом не производит никаких операций над "Хранителем" и не исследует его внутреннее содержимое. "Посыльный" запрашивает "Хранитель" у "Хозяина", некоторое время держит его у себя, а затем возвращает "Хозяину".
Преимущества	Не раскрывается информация, которая доступна только "Хозяину", упрощается структура "Хозяина".
Недостатки	С использованием "Хранителей" могут быть связаны значительные издержки, если "Хозяин" должен копировать большой объём информации, или если копирование должно проводиться часто.

Информационный эксперт (Information Expert)- GRASP

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

Интеграция на основе единой понятийной модели предметной области (concept-centric).

Задача

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

Решение

Средством решения проблемы интеграции второго уровня является разработка ОЯВ компонентов, основанного на единой понятийной модели, описывающей объекты предметной области, их взаимосвязи и поведение. Как правило, ОЯВ является языком сообщений высокого уровня и имеет достаточно простой синтаксис и естественно-языковую лексику на основе бизнес-объектов. Единая понятийная модель представляет собой базу метаданных, хранящую описания интерфейсных бизнес-объектов каждого из компонентов и отношения (связи) между этими объектами. Между интегрируемыми компонентами и их описаниями в базе метаданных должно поддерживаться постоянное соответствие. Хранящиеся в базе метаданных описания и сам язык взаимодействия строятся как независимые от конкретного интегрирующего программного обеспечения. Преобразование сообщений на ОЯВ в вызовы функций той или иной интегрирующей среды обеспечивается дополнительной интегрирующей оболочкой с единым интерфейсом, который предназначен только для обмена сообщениями на ОЯВ. Единицей информационного обмена в рассматриваемом подходе являются сообщения, поэтому целесообразно строить такое программное обеспечение на основе программных продуктов класса MOM.

Интеграция систем по данным (data-centric).

Описание

Данный поход был исторически первым в решении проблемы интеграции приложений. Этот подход характерен для традиционных систем "клиент-сервер". При интеграции приложений по данным считается, что основным системообразующим фактором при построении информационной системы является интегрированная база данных коллективного доступа. Концепция интеграции в этом подходе состоит в том, что приложения объединяются в систему вокруг интегрированных данных под управлением СУБД. Интегрирующей средой является промышленная СУБД (как правило, реляционная) со стандартным интерфейсом доступа к данным (обычно это доступ на SQL). Все функции прикладной обработки размещаются в клиентских программах.

Недостатки

Необходимость передачи больших объемов данных.

Интерпретатор (Interpreter ) - GoF

Проблема	Имеется часто встречающаяся, подверженная изменениям задача.
Решение	Создать интерпретатор, который решает данную задачу.
Пример	Задача поиска строк по образцу может быть решена посредством создания интерпретатора, определяющего грамматику языка. "Клиент" строит предложение в виде абстрактного синтаксического дерева, в узлах которого находятся объекты классов "НетерминальноеВыражение" и "ТерминальноеВыражение" (рекурсивное), затем "Клиент" инициализирует контекст и вызывает операцию Разобрать(Контекст). На каждом узле типа "НетерминальноеВыражение" определяется операция Разобрать для каждого подвыражения. Для класса "ТерминальноеВыражение" операция Разобрать определяет базу рекурсии. "АбстрактноеВыражение" определяет абстрактную операцию Разобрать, общую для всех узлов в абстрактном синтаксическом дереве. "Контекст" содержит информацию, глобальную по отношению к интерпретатору.
Преимущества	Грамматику становится легко расширять и изменять, реализации классов, описывающих узлы абстрактного синтаксического дерева похожи (легко кодируются). Можно легко изменять способ вычисления выражений.
Недостатки	Сопровождение грамматики с большим числом правил затруднительно.

Искусственный (Pure Fabrication) - GRASP

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

Итератор (Iterator) или Курсор (Cursor) - GoF

Проблема	Составной объект, например, список, должен предоставлять доступ к своим элементам (объектам), не раскрывая их внутреннюю структуру, причем перебирать список требуется по-разному в зависимости от задачи.
Решение	Создается класс "Итератор", коорый определяет интерфейс для доступа и перебора элементов, "КонкретныйИтератор" реализует интерфейскласса "Итератор" и следит за текущей позицией при обходе "Агрегата". "Агрегат" определяет интерфейс для создания объекта - итератора. "КонкретныйАгрегат" реализует интерфейс создания итератора и возвращает экземпляр класса "КонкретныйИтератор", "КонкретныйИтератор" отслеживает текущий объект в агрегате и может вычислить следующий объект при переборе.
Преимущества	Поддерживает различные способы перебора агрегата, одновременно могут быть активны несколько переборов.

Клиент/сервер

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

Коллекция обьектов (Identity Map)

Задача	Требуется гарантировать, что каждый объект будет загружен из базы данных только один раз.
Решение	Создать специальную коллекцию обьектов, загруженных из базы данных в пределах одной бизнес - транзакции. Таким образом, при получении запроса можно просмотреть эту коллекцию в поисках нужного объекта.
Преимущества	Предотвращение повторных загрузок позволяет избежать ошибок и повышает производительность системы.

Команда (Command), Действие (Action) или Транзакция (Транзакция) - GoF

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

Компоновщик (Composite) - GoF

Проблема	Как обрабатывать группу или композицию структур обьектов одновременно?
Решение	Определить классы для композитных и атомарных обьектов таким образом, чтобы они реализовывали один и тот же интерфейс.
Пример	См. паттерн "Стратегия", 3.2.9, необходимо учесть несколько скидок различных видов (зависят от времени, типа покупателя, типом выбранного продукта. Как применять политику ценообразования? Вырабатывается стратегия приоритета скидок, объект "Продажа" не должен обладать информацией о применяемых скидках, но можно было бы применить стратегию расчета скидок. Создается новый класс "РасчетСкидкиАлгоритмКомпозит".

Контроллер (Controller) - GRASP

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

ЛИТЕРАТУРА

[1] K. Alexander et al. Pattern Language. Oxford 1977.
[2] К. Ларман. Применение UML и паттернов проектирования. М. , Вильямс, 2002.
[3] Г. Буч, Дж. Рамбо, А. Джекобсон. Язык UML. Руководство пользователя. М. LVR Пресс, 2001.
[4] Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы обьектно - ориентированного проектирования Паттерны Проектирования. СПб., Питер, 2003.
[5] М. Фаулер. Архитектура корпоративных программных приложений. М. , Вильямс, 2004.
[6] G. Hohpe, B. Woolf. Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions. Addison-Wesley, 2004.

Многоуровневая система (Layers) или абстрактная машина

Описание	В соответствии с паттерном "Многоуровневая система" структурные элементы системы организуются в отдельные уровни со взаимосвязанными обязанностями таким образом, чтобы на нижнем уровне располагались низкоуровневые службы и службы общего назначения, а на более высоких - объекты уровня логики приложения. При этом взаимодействие и связывание уровней происходит сверху вниз. Связывания обьектов снизу вверх следует избегать. На рисунке показаны типичные уровни логической архитектуры системы . Слой представления охватывает все, что имеет отношение к общению пользователя с системой. К главным функциям слоя представления относится отображение информации и интерпретация вводимых пользователем команд с преобразованием их в соответствующие операции в контексте домена (бизнес - логики) и источника данных. Источник данных - подмножество функций, обеспечивающих взаимодействие со сторонними системами, которые выполняют В отличие от архитектурного паттерна "Клиент - сервер" 4.1.2, слои вовсе не обязательно должны располагаться на разных машинах.
Пример	Примером данного подхода может служить модель взаимодействия открытых систем (OSI - Open System Interconnection - международная программа стандартизации обмена данными между компьютерными системами на основе семиуровневой модели протоколов передачи данных в открытых системах).
Преимущества	Многоуровневая система может быть разработана пошагово (итеративно).
Недостатки	Изменение исходного кода влечет за собой переделку всех элементов системы, поскольку все элементы системы тесно связаны друг с другом. Логика приложения тесно связана с интерфейсом пользователя - затруднительно менять интерфейс или принципы реализации логики. Из-за высокой связанности, работу по реализации системы сложно разделить между разработчиками и, кроме того, сложно модифицировать функции приложения или переходить на новые технологии.

Мост (Bridge), Handle (описатель) или Тело (Body) - GoF

Проблема	Требуется отделить абстракцию от реализации так, чтобы и то и другое можно было изменять независимо. При использовании наследования реализация жестко привязывается к абстракции, что затрудняет независимую модификацию.
Решение	Поместить абстракцию и реализацию в отдельные иерархии классов.
Рекомендации	Можно использовать если, например, реализацию необходимо выполнять во время реализации программы.
Пример	"Абстракция" определяет интерфейс "Абстракции" и хранит ссылку на объект "Реализация", "УточненнаяАбстракция" расширяет интерфейс, определенный "Абстракцией". "Реализация" определяет интерфейс для классов реализации, он не обязан точно соответствовать интерфейсу класса "Абстракция" - оба интерфейса могут быть совершенно различны. Обычно интерфецйс класса "Реализация" предоставляет только примитивные операции, а класс "Абстракция" определяет операции более высокого уровня, базирующиеся на этих примитивных. "КонкретнаяРеализация" содержит конкретную реализацию класса "Реализация". Объект "Абстракция" перенаправляет своему объекту "Реализация" запросы "Клиента".
Преимущества	Отделение реализации от интерфейса, то есть, "Реализацию" "Абстракции" можно конфигурировать во время выполнения. Кроме того, следует упомянуть, что разделение классов "Абстракция" и "Реализация" устраняет зависимости от реализации, устанавливаемые на этапе компиляции: чтобы изменить класс "Реализация" вовсе не обязательно перекомпилировать класс "Абстракция".

Наблюдатель (Observer), Опубликовать

Проблема

Один объект ("Подписчик") должен знать об изменении состояний или некоторых событиях другого объекта. При этом необходимо поддерживать низкий уровень связывания с объектом - "Подписчиком".

Решение

Определить интерфейс "Подписки". Объекты - подписчики реализуют этот интерфейс и динамически регистрируются для получении информации о некотором событии. Затем при реализации условленного события оповещаются все объекты - подписчики.

Наследование с одной таблицей (Single Table Inheritance)

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

Не разговаривайте с неизвестными (Don't talk to strangers) - GRASP

Проблема	Обеспечить связь клиентского объекта с непрямыми объектами (то есть известными другим объектам, а не самому клиенту).
Решение	Необходимо избегать проектных решений, предполагающих передачу сообщений с удаленными непрямыми объектами (незнакомцами). Решением может быть частный случай паттерна "Устойчивый к изменениям", см. . Прямым объектом потребуются новые операции.
Преимущества	Обеспечивает устойчивость системы к изменению структуры обьектов.

Низкая связанность (Low Coupling) - GRASP

Проблема	Обеспечить низкую связанность при создании экземпляра класса и связывании его с другим классом.
Решение	Распределить обязанности между объектами так, чтобы степень связанности оставалась низкой.
Пример	Необходимо создать экземпляр класса "Платеж". В предметной области регистрация объекта "Платеж" выполняется объектом "Регистрация" (ведется рестр). Ниже приводятся 2 способа создания экземпляра класса "Платеж". Верхний рисунок - с использованием паттерна "Создатель", нижний - с использованием "Низкая связанность". Последний способ обеспечивает более низкую степень связывания.

Объектно-центрический (object-centric).

Описание

Объектно-центрический подход, основанный на стандартах объектного взаимодействия CORBA, COM/DCOM, .NET и пр. и является композицией типов объединения систем по данным и обьектно - центрического. Концепция интеграции в состоит в том, что системы объединяются вокруг общедоступных распределенных объектов со стандартными интерфейсами. Характерными особенностями данного подхода являются: " унифицированный язык спецификации интерфейсов объектов (например IDL); " отделение реализации компонентов от спецификации их интерфейсов; " общий механизм поддержки взаимодействия объектов (брокер объектных запросов, играющий роль "общей шины", поддерживающей взаимодействие объектов). Интегрирующей средой является брокер объектных запросов с интерфейсом в стандарте CORBA или DCOM. Общая архитектура системы формируется на основе распределенных объектов и является n-звенной.

Обьектно - ориентированный, Модель предметной области (Domain Model), модуль таблицы (Data Mapper)

Задача	Бизнес - логика крайне сложна, имеется множество правил и условий, оговаривающих различные варианты поведения системы.
Решение	Система представляется состоящей из совокупности связанных между собой обьектов. Объекты представляют сервисы (методы) другим объектам и создаются во время исполнения программы на основе определения классов обьектов. Объекты скрывают информацию о представлении состояний и, следовательно, ограничивают к ним доступ.
Преимущества	Упрощается процесс модификации системы: можно изменять реализацию того или иного объекта, не воздействуя на другие объекты. Обьектно - ориентированная система проще в понимании и модернизации. Данная система удобна для групповой разработки: работу по реализации системы легко разделить между разработчиками. Потенциально все объекты являются повторно используемыми компонентами, так как они независимо инкапсулируют данные о состоянии и операции. Архитектуру системы можно разрабатывать на базе обьектов (структур обьектов) уже созданных в предыдущих проектах.
Недостатки	При использовании сервисов объекты должны явно ссылаться на имена других обьектов и знать их интерфейс (это необходимо учесть если при изменении системы требуется изменить интерфейс).
Пример 1.	Модель предметной области может быть рассмотрена как частный случай данного паттерна. Каждый объект наделяется только функциями, отвечающими его природе. На диаграмме показано вычисление зачтенного дохода с помощью модели предметной области, см. пример из п. .
Пример 2.	Модуль таблицы также является частным случаем данного паттерна. В отличие от модели предметной области Модуль таблицы содержит по одному объекту Контракт для каждого контракта, а Модуль таблицы является единственным объектом. Модуль таблицы используется совместно с множеством записей (Record Set). Сначала создается объект "Контракт", затем - "Продукт", множество записей передается ему в качестве аргумента.. Для совершения операций над отдельным контрактом, следует сообщить объекту соответствующий идентификатор (Id). Модуль таблицы представляет собой промежуточный вариант между "Сценарием транзакции" 4.2.1.1 и "Моделью предметной области" (Пример1).

Обмен сообщениями

Описание

Данный тип интеграции приложений основан на асинхронном обмене сообщениям посредством шины данных и предназначен для интеграции независимых приложений без или с минимальными доработками существующих систем. Он является реализацией подхода 5.2.4. При этом за логику интеграции отвечает интеграционная шина в отличие от других типов интеграции, где за логику интеграции отвечала одна из интегрируемых систем. Такой подход позволяет легко интегрировать новые системы, а также изменять логику интеграции, легко приводя ее в соответствие с бизнес логикой процесса.
Обмен сообщениями

Общая база данных

Описание

Является реализацией подхода 5.2.1. Данный тип интеграции позволяет получить полностью интегрированную систему приложений, работающую с едиными данными в любой момент времени. Изменения, произведенные в одном из приложений, автоматически отражаются в другом. За корректность данных отвечает многопользовательская СУБД.
Общая база данных

Затруднительно интегрировать существующие системы, удобно использовать для вновь создаваемых.

систем.

Общие термины - часть

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

паттерн проектирования объектов - GoF - паттерны, разработанные четырьмя авторами , GRASP (General Responsibility Assignment Software Patterns) - паттерны распределения обязанностей между объектами ;
архитектурный системный паттерн - крупномасштабное проектное решение при разработке системы, обычно формируется на ранних итерациях ;
паттерн интеграции систем - используется при интеграции нескольких систем .

Общие термины

Rational Rose - инструмент для визуального моделирования объектно-ориентированных информационных систем компании Rational Software. Продукт использует UML.
API (Application Programming Interface) - интерфейс программирования прикладных систем.
UML (Unified Modeling Language) - унифицированный язык моделирования обьектно - ориентированных программных систем.
Анализ - исследование обьектов и процессов предметной области, кроме того, данный термин может означать исследование требований к системе, имеющегося функционала системы и пр.
Архитектура системы - организация и структура основных элементов системы, имеющая принципиальное значение для функционирования системы в целом.
Диаграмма - графическое представление набора элементов разрабатываемой системы или предметной области, в вершинах данного представления находятся сущности, а дуги представляют собой отношения этих сущностей. Диаграммы строятся в рамках определенной модели. Например, в рамках UML строятся следующие диаграммы: - прецедентов (описывает функциональное назначение системы), - концептуальных классов (описывает предметную область), - состояний (описывает поведения зависимых от состояний обьектов системы), - деятельности (используется для алгоритмического описания поведения системы) - программных классов, - взаимодействия (описывает взаимодействие обьектов системы).
Проектирование - выработка концептуальных решений, обеспечивающих выполнение основных требований и разработка системной спецификации.
Модель - представление разрабатываемой системы или предметной области в рамках определенного стандарта, например, модель данных системы, выполненная c использованием стандарта IDEF1X.
Модуль - компонент системы (подсистемы), который предоставляет один или несколько сервисов. Модуль может использовать сервисы, поддерживаемые другими модулями. Модуль не может рассматриваться как независимая система.
Подсистема - часть системы, которая выделяется при проектировании архитектуры. Операции выполняемые подсистемой не зависят от сервисов, предоставляемых другими подсистемами, и, кроме того, подсистемы имеют интерфейсы, посредством которых взаимодействуют с другими подсистемами.

Одиночка (Singleton) - GoF

Проблема	Какой специальный класс должен создавать "Абстрактную фабрику", см. и как получить к ней доступ? Необходим лишь один экземпляр специального класса, различные объекты должны обращаться к этому экземпляру через единственную точку доступа.
Решение	Создать класс и определить статический метод класса, возвращающий этот единственный объект.
Рекомендации	Разумнее создавать именно статический экземпляр специального класса, а не объявить требуемые методы статическими, поскольку при использовании методов экземпляра можно применить механизм наследования и создавать подклассы. Статические методы в языках программирования не полиморфны и не допускают перекрытия в производных классах. Решение на основе создания экземпляра является более гибким, поскольку впоследствии может потребоваться уже не единственный экземпляр объекта, а несколько.

Оптимистическая автономная блокировка (Optimistic Offline Lock)

Задача

Бизнес - транзакция содержит несколько системных транзакций, см. п. в этом случае СУБД не может гарантировать согласованность записей базы данных. Любая попытка доступа нескольких сеансов к одним и тем же записям грозит нарушением целостности данных и, кроме того, может привести к утрате внесенных изменений.

Решение

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

Отображение с помощью таблицы ассоциаций (Association Table Mapping)

Описание	Требуется организовать в реляционной базе данных отображение связи "многие - ко -многим".
Решение	Создать специальную таблицу отношений для хранения ассоциаций. При этом каждой паре взаимосвязанных обьектов будет соответствовать только одна строка таблицы отношений.
Недостатки	Обновление данных занимает значительное время.

Отображение с помощью внешних ключей

Описание	Требуется организовать в реляционной базе данных отображение связи "один - ко -многим" (в отличие от базы данных для объекта легко реализовать многозначный атрибут - достаточно просто сделать коллекцией значение данного аттрибута).
Решение	Ссылку на коллекцию обьектов можно сохранить в базе данных путем сохранения в зависимой таблицы идентификатора главного объекта. При этом будет обеспечена возможность обновления согласованной информации в базе данных.

ПАТТЕРНЫ ИНТЕГРАЦИИ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

Паттерны интеграции информационных систем представляют собой , как это описано в разделе 2, верхний уровень классификации паттернов проектирования. Аналогично паттернам более низких уровней классификации, среди паттернов интеграции выделена группа структурных паттернов, см. . Структурные паттерны описывают основные компоненты единой интегрированной метасистемы. В свою очередь, для описания взаимодействия отдельных корпоративных систем, включенных в интегрированную метасистему, организована группа паттернов, объединенных в соответствии с тем или иным методом интеграции, см. . Далее, интеграция корпоративных информационных систем подразумевает тем или иным способом организованный обмен данными между системами. Для организации обмена информацией между отдельными системами, включенными в интегрированную метасистему, служит раздел 5.3. Следует отметить, что в отличие от паттернов проектирования классов/обьектов и архитектурных системных паттернов, отнесение отдельного паттерна интеграции к тому или иному виду является менее условным.

ПАТТЕРНЫ ПРОЕКТИРОВАНИЯ КЛАССОВ/ОБЬЕКТОВ

Согласно классификации, предложенной в предыдущем разделе, описание системы в терминах классов/обьектов следует считать низшим уровнем ее представления. В свою очередь, при моделировании системы на уровне классов/обьектов обычно проводят дополнительную типологизацию в двух аспектах, а именно, описывают структуру системы в терминах микроскопических элементов (см. ) и то, каким образом такая система обеспечивает требуемый функционал. Соответственно, среди паттернов проектирования выделены структурные паттерны, см. и паттерны распределения обязанностей между классами/объектами, 3.2. Поскольку отдельные объекты создаются и уничтожаются в процессе работы системы, выделена еще одна большая группа паттернов проектирования, которые служат для создания обьектов, 3.3.
Необходимо отметить наличие еще одной классификации паттернов, которое очевидно из наименования данного раздела: паттерны проектирования классов и паттерны проектирования обьектов (определения класса и объекта см. в ). В качестве примера паттернов проектирования классов можно привести "Фабричный метод", "Шаблонный метод"; паттернов проектирования обьектов - "Абстрактную фабрику", "Хранителя" и др.
Кроме этого необходимо отметить, что некоторые паттерны проектирования обьектов часто используются совместно, например, паттерн "Компоновщик" часть применяется вместе с "Итератором" или "Посетителем". Помимо этого, одну и ту же задачу можно решить используя различные паттерны проектирования классов/обьектов в качестве альтернативы, так, например, "Прототип" зачастую используют вместо "Абстрактной фабрики".

Передача сообщений

Описание	В рамках данного паттерна событие представляет собой передачу сообщения всем подсистемам. Любая подсистема, которая обрабатывает данное событие, отвечает на него.
Рекомендации	Данный подход эффективен при интеграции подсистем, распределенных на разных компьютерах, которые объединены в сеть.

Перенаправление (Indirection) - GRASP

Проблема	Как перераспределить обязанности обьектов, чтобы обеспечить отсутствие прямого связывания?
Решение	Присвоить обязанности по обеспечению связи между службами или компонентами промежуточному объекту.
Пример	См. пример к паттерну "Искусственный" 3.2.16. Класс "Хранилище" выступает в роли промежуточного звена между классом "Продажа" и базой данных.

Пессимистическая автономная блокировка (Pessimistic Offline Lock)

Задача	При использовании оптимистической блокировки один пользователь может зафиксировать результаты транзакции, а остальным пользователям будет в этом отказано. Требуется предотвратить подобный конфликт.
Решение	Блокировка накладывается на данные прежде, чем бизнес - транзакция начинает с ними работать, таким образом, гарантируется завершение транзакции без негативных последствий из-за параллельных сеансов.
Рекомендации	Пессимистическая блокировка должна применяться в том случае, когда велика вероятность конфликта.
Примечание	Альтернативой применению "Пессимистической блокировки" может быть использование длинных системных транзакций.

Поле идентификации (Identity Field)

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

Полиморфизм (Polymorphism) - GRASP

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

Посетитель (Visitor) - GoF

Проблема	Над каждым объектом некоторой структуры выполняется операция. Определить новую операцию, не изменяя классы обьектов.
Решение	Клиент, использующий данный паттерн, должен создать объект класса "КонкретныйПосетитель", а затем посетить каждый элемент структуры. "Посетитель" объявляет операцию "Посетить" для каждого класса "КонкретныйЭлемент" (имя и сигнатура данной операции идентифицируют класс, элемент которого посещает "Посетитель" - то есть, посетитель может обращаться к элементу напрямую). "КонкретныйПосетитель" реализует все операции, обьявленные в классе "Посетитель". Каждая операция реализует фрагмент алгоритма, определенного для класса соответствующего объекта в структуре. Класс "КонкретныйПосетитель"предоставляет контекст для этого алгоритма и сохраняет его локальное состояние. "Элемент" определяет операцию "Принять", которая принимает "Посетителя" в качестве аргумента, "КонкретныйЭлемент" реализует операцию "Принять", которая принимает "Посетителя" в качестве аргумента. "СтруктураОбьекта" может перечислить свои аргументы и предоставить посетителю высокоуровневый интерфейс для посещения своих элементов.
Рекомендации	Логично использовать, если в структуре присутствуют объекты многих классов с различными интерфейсами, и необходимо выполнить над ними операции, зависящие от конкретных классов, или если классы, устанавливающие структуру обьектов изменяются редко, но новые операции над этой структурой добавляются часто.
Преимущества	Упрощается добавление новых операций, объединяет родственные операции в классе "Посетитель".
Недостатки	Затруднено добавление новых классов "КонкретныйЭлемент", поскольку требуется объявление новой абстрактной операции в классе "Посетитель".

Посредник (Mediator) - GoF

Проблема	Обеспечить взаимодействие множества обьектов, сформировав при этом слабую связанность и избавив объекты от необходимости явно ссылаться друг на друга.
Решение	Создать объект инкапсулирующий способ взаимодействия множества обьектов.
Пример	"Посредник" определяет интерфейс для обмена информацией с объектами "Коллеги", "КонкретныйПосредник" координирует действия обьектов "Коллеги". Каждый класс "Коллеги" знает о своем объекте "Посредник", все "Коллеги" обмениваются информацией только с посредником, при его отсутствии им пришлось бы обмениваться информацией напрямую. "Коллеги" посылают запросы посреднику и получают запросы от него. "Посредник" реализует кооперативное поведения, пересылая каждый запрос одному или нескольким "Коллегам".
Преимущества	Устраняется связанность между "Коллегами", централизуется управление.

Потоки данных (конвейер или фильтр)

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

Преобразователь данных (Data Mapper)

Описание	При переходе от полей "Шлюза таблицы данных", 4.2.3.17, к полям обьектов "Модели предметной области", 4.1.3, приходится выполнять определенные преобразования, которые приводят к усложнению обьектов домена.
Решение	Изолировать "Модель предметной области" от базы данных, возложив на промежуточный слой всю полноту ответственности за отображение обьектов домена в таблицы базы данных. Преобразователь данных обслуживает все операции загрузки и сохранения информации, инициируемые бизнес - логикой и позволяет независимо модернизировать как "Модель предметной области" так и схему базы данных.
Преимущества	Полная изоляция бизнес - логики от базы данных.

ПРИНЦИП КЛАССИФИКАЦИИ ПАТТЕРНОВ ПРОЕКТИРОВАНИЯ

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

Приспособленец (Flyweight) - GoF

Проблема	Необходимо обеспечить поддержку множества мелких обьектов.
Рекомендации	Приспособленцы моделируют сущности, число которых слишком велико для представления объектами. Имеет смысл использовать данный паттерн если одновременно выполняются следующие условия: в приложении используется большое число обьектов, из-за этого расходы на хранение высоки, большую часть состояния обьектов можно вынести вовне, многие группы обьектов можно заменить относительно небольшим количеством обьектов, поскольку состояния обьектов вынесены вовне.
Решение	Создать разделяемый объект, который можно использовать одновременно в нескольких контекстах, причем, в каждом контексте он выглядит как независимый объект (неотличим от экземпляра, который не разделяется). "Приспособленец" объявляет интерфейс, с помощью которого приспособленцы могут получить внешнее состояние или как-то воздействовать на него, "КонкретныйПриспособленец" реализует интерфейс класса "Приспособленец" и добавляет при необходимости внутреннее состояние. Внутреннее состояние хранится в объекте "КонкретныйПриспособленец", в то время как внешнее состояние хранится или вычисляется "Клиентами" ("Клиент" передает его "Приспособленцу" при вызове операций). Объект класса "КонкретныйПриспособленец" должен быть разделяемым. Любое сохраняемое им состояние должно быть внутренним, то есть независимым от контекста, "ПриспособленецФабрика" - создает объекты - "Приспособленцы" (или предоставляет существующий экземпляр) и управляет ими. "НеразделяемыйКонкретныйПриспособленец" - не все подклассы "Приспособленца" обязательно должны быть разделяемыми. "Клиент" - хранит ссылки на одного или нескольких "Приспособленцев", вычисляет и хранит внешнее состояние "Приспособленцев".
Преимущества	Вследствие уменьшения общего числа экземпляров и вынесения состояния экономится память.

Прототип (Prototype) - GoF

Проблема	Система не должна зависеть от того, как в ней создаются, компонуются и представляются объекты.
Решение	Создавать новые объекты с помощью паттерна - прототипа. "Прототип" объявляет интерфейс для клонирования самого себя. "Клиент" создает новый объект, обращаясь к "Прототипу" с запросом клонировать "Прототип".

Репозиторий

Описание	Все совместно используемые подсистемами данные хранятся в центральной базе данных, доступной всем подсистемам. Репозиторий является пассивным элементом, а управление им возложено на подсистемы.
Рекомендации	Логично использовать, если система обрабатывает большие объёмы данных.
Преимущества	Совместное использование больших объёмов данных эффективно, поскольку не требуется передавать данные из одной подсистемы в другие. Подсистема не должна знать, как используются данные в других подсистемах - уменьшается степень связывания. В системах с репозиторием резервное копирование, обеспечение безопасности, управление доступом и восстановление данных централизованы, поскольку входят в систему управления репозиторием.
Недостатки	Все подсистемы должны быть согласованы со структурой репозитория (моделью данных). Модернизировать модель данных достаточно трудно К разными подсистемам предъявляются различные требования по безопасности, восстановлению и резервированию данных, а в паттерне Репозиторий ко всем подсистемам применяется одинаковая политика.

Шаблонный метод (Template Method) - GoF

Проблема	Определить алгоритм и реализовать возможность переопределения некоторых шагов алгоритма для подклассов (без изменения общей структуры алгоритма.
Решение	"АбстрактныйКласс" определяет абстрактные Операции(), замещаемые в конкретных подклассах для реализации шагов алгоритма, и реализует ШаблонныйМетод(), определяющий "скелет" алгоритма. "КонкретныйКласс" релизует Операции(), выполняющие шаги алгоритма способом, который зависит от подкласса. "КонкретныйКласс" предполагает, что инвариантные шаги алгоритма будут выполнены в "АбстрактномКлассе".

Шлюз таблицы данных (Table Data Gateway)

Задача	Обеспечить взаимодействие бизнес - логики с базой данных, при этом требуется обособить SQL код от бизнес - логики.
Решение	Копировать структуру таблицы базы данных в отдельном классе, который содержит методы активизации запросов, возвращающих множество записей.

Шлюз записи данных (Row Data Gateway)

Задача	Обеспечить взаимодействие бизнес - логики с базой данных, при этом требуется обособить SQL код от бизнес - логики.
Решение	Копировать структуру записи в отдельном классе. Для каждой записи, возвращаемой запросом к базе данных, создается экземпляр шлюза.

Смешанный способ взаимодействия

Описание

В данном способе совмещены 5.1.1 и 5.1.2 подходы к взаимодействию систем. При этом интерфейсы частично могут использоваться непосредственно напрямую в обход интегрирующей среды. Указанный способ сочетает в себе преимущества централизации управления процессами взаимодействия систем, унификации интерфейсов, а также возможность использовать прямые интерфейсы между системами. Необходимость использования прямых интерфейсов в обход интегрирующей среды может диктоваться, например, специфическими требованиями безопасности.
Смешанный способ взаимодействия

Состояние (State) - GoF

Проблема	Варьировать поведение объекта в зависимости от его внутреннего состояния
Решение	Класс "Контекст" делегирует зависящие от состояния запросы текущему объекту "КонкретноеСостояние" (хранит экземпляр подкласса "КонкретноеСостояние", которым определяется текущее состояние), и определяет интерфейс, представляющий интерес для клиентов. "КонкретноеСостояние" реализует поведение, ассоциированное с неким состоянием объекта "Контекст". "Состояние" определяет интерфейс для инкапсуляции поведения, ассоциированного с конкретным экземпляром "Контекста".
Преимущества	Локализует зависящее от состояния поведение и делит его на части, соответствующие состояниям, переходы между состояниями становятся явными.

Создатель экземпляров класса (Creator) - GRASP

Проблема	"Кто" должен отвечать за создание экземпляров класса.
Решение	Назначить классу В обязанность создавать объекты другого класса А
Рекомендации	Логично использовать паттерн если класс В содержит, агрегирует, активно использует и т.п. объекты класса А.
Пример	См. пример к паттерну "Информационный эксперт" в п. , необходимо определить, какой объект должен отвечать за создание экземпляра "ТоварПродажа". Логично, чтобы это был объект "Продажа", поскольку он содержит (агрегирует) несколько обьектов "ТоварПродажа".
Преимущества	Использование этого паттерна не повышает связанности, поскольку созданный класс, как правило, виден только для класса - создателя.
Недостатки	Если процедура создания объекта достаточно сложная (например выполняется на основе некоего внешнего условия), логично использовать паттерн "Абстрактная Фабрика", см. , то есть, делегировать обязанность создания обьектов специальному классу.

Стратегия (Strategy) - GoF

Проблема	Спроектировать изменяемые, но надежные алгоритмы или стратегии.
Решение	Определить для каждого алгоритма или стратегии отдельный класс со стандартным интерфейсом.
Пример	Обеспечение сложной логики вычисления стоимости товаров с учетом сезонных скидок, скидок постоянным клиентам и т. п. Данная стратегия может изменяться. Создается несколько классов "Стратегия", каждый из которых содержит один и тот же полиморфный метод "ЦенаРассчитать". В качестве параметров в этот метод передаются данные о продаже. Объект стратегии связывается с контекстным объектом (тем объектом, к которому применяется алгоритм).

Строитель (Builder) - GoF

Проблема	Отделить конструирование сложного объекта от его представления, так чтобы в результате одного и того же конструирования могли получаться различные представления. Алгоритм создания сложного объекта не должен зависеть от того, из каких частей состоит объект и как они стыкуются между собой.
Решение	"Клиент" создает объект - распорядитель "Директор" и конфигурирует его объектом - "Строителем". "Директор" уведомляет "Строителя" о том, что нужно построить очередную часть "Продукта". "Строитель" обрабатывает запросы "Директора" и добавляет новые части к "Продукту", затем "Клиент" забирает "Продукт" у "Строителя".
Преимущества	Объект "Строитель" предоставляет объекту "Директор" абстрактный интерфейс для конструирования "Продукта", за которым может скрыть представление и внутреннюю структуру продукта, и , кроме того, процесс сборки "продукта". Для изменения внутреннего представления "Продукта" достаточно определить новый вид "Строителя". Данный паттерн изолирует код, реализующий создание объекта и его представление.

Термины архитектурных системных паттернов

Реляционная база данных - база данных, построенная на реляционной модели. Информация в реляционной базе данных хранится в виде связанных таблиц, состоящих из столбцов и строк.
Сеанс - долговременный процесс взаимодействия клиента и сервера, обычно начинается с подключения клиента к системе, включает отправку запросов, выполнение одной или нескольких бизнес - транзакций и пр.
СУБД - система управления базами данных, комплекс программных и семантических средств, реализующий поддержку создания баз данных, централизованного управления и организации доступа к ним различных пользователей в условиях принятой технологии обработки данных.
Транзакция - ограниченную последовательность действий с базой данных с явно определенными начальной и завершающими операциями. Следует выделить следующие свойства транзакций: атомарность (в рамках транзакции выполняются все действия, либо не выполняется ни одно), согласованность (системные ресурсы должны пребывать в целостном и непротиворечивом состоянии после проведения транзакции), изолированность (промежуточные результаты транзакции должны быть закрыты для доступа со стороны любой другой транзакции до проведения их фиксации) , устойчивость (результат проведения транзакции не должен быть утрачен). Выделяют системные транзакции, то есть группу SQL - команд в совокупности с командами начала и завершения и бизнес - транзакции, то есть совокупность определенных действий, инициируемых пользователем системы. В качестве примера бизнес - транзакции можно привести регистрацию пользователя, выбор счета, ввод требуемой суммы и подтверждение проведенной операции. Выполнение бизнес - транзакции, как правило, охватывает несколько системных транзакций.

Термины паттернов интеграции

Активная система - система, использующая интерфейс другой системы.
Пассивная система - система, предоставляющая интерфейсы для пользования другим системам и не использующая напрямую интерфейсы других систем.
Интегрирующая среда - совокупность программных и организационных составляющих, целью которых является обеспечение взаимодействия систем и образование единой системы. Наличие интегрирующей среды позволяет говорить о целостности единой системы, а не о наборе отдельных приложений.
ОЯВ - общесистемный язык взаимодействия.
EAI (Enterprise Application Integration) - Интеграция корпоративных систем.
IDL (Interface Definition Language) - язык спецификации интерфейсов.
MOM (Message Oriented Middleware) - системное программное обеспечение промежуточного слоя, ориентированное на обмен сообщениями.
XML (eXtensile Markup Language)- расширяемый язык гипертекстовой разметки, используемый в интернете. Язык XML использует структуру тегов и определяет содержание гипертекстового документа. XML позволяет автоматизировать обмен данными, при этом обьем программирования будет незначительным.
XSLT (eXtensible Stylesheet Language for Transformations) - предназначен для преобразования XML документов. С его помощью можно описать правила преобразования, которые позволят преобразовать документ в другую форму (структуру) или формат, например, в текстовый или HTML.

Термины паттернов проектирования объектов

Зацепление (cohesion) - мера "сфокусированности" обязанностей класса. Класс с низкой степенью зацепления выполняет много разнородных функций и несвязанных между собой обязанностей. Создавать такие классы нежелательно.
Инкапсуляция - механизм, используемый для сокрытия данных, внутренней структуры и деталей объекта, все взаимодействие обьектов выполняется через интерфейс операций.
Инстанцирование - создание экземпляра класса.
Интерфейс объекта (системы) - совокупность сигнатур всех определенных для объекта (системы) операций.
Класс специфицирует внутренние данные объекта и его представление, а также операции, которые объект может выполнять. Класс в языке UML (программный или концептуальный) -это описание набора элементов, имеющих одинаковые атрибуты, операции и отношения. Абстрактный класс делегирует свою реализацию подклассам, его единственным назначением является спецификация интерфейса.
Наследование - это отношение, которое определяет одну сущность в терминах другой. В качестве примера можно привесит создание специализированных подклассов (классов - потомков) на основе более общих суперклассов (классов-предков). При этом атрибуты и операции суперкласса автоматически присваиваются подклассу, и, кроме того, подкласс может иметь новые операции и атрибуты. Это позволяет избавиться от необходимости создавать подкласс "с нуля".
Объект - экземпляр класса. В процессе создания объекта выделяется память для переменных - атрибутов класса (внутренних данных класс) и с этими данными ассоциируются операции. Объект существует во время выполнения программы, хранит данные и операции для работы с этими данными, при этом данные объекта могут быть изменены только с помощью операций.
Полиморфизм - отношение, при котором различные сущности (связанные отношением наследования ) по - разному реагируют на одно и то же сообщение, например, различная реакция подклассов одного класса на одно и то же сообщение.
Принцип разделения обязанностей - разделение различных аспектов функционирования системы, то есть, разделение системы на элементы, соответствующие разным аспектам функционирования и задачам. Например, программные объекты уровня предметной области должны отвечать только за реализацию логики приложения, а взаимодействие с внешними службами должны обеспечивать отдельные группы обьектов.
Связанность (coupling) - зависимость между классами, вызываемая взаимодействием между ними при выполнении определенной задачи. Класс с высокой степенью связанности зависит от множества других классов, что нежелательно.
Сигнатура операции - имя операции, передаваемые параметры и возвращаемые значения.
Системное событие - событие, генерируемое внешним исполнителем.

Удаленный вызов процедур

Описание	Данный тип интеграции является реализацией объектно-центрического подхода, 5.2.3. При таком подходе приложения интегрированы на уровне функций. Изменение данных в другой системе происходит также посредством вызова функций.
Недостатки	Каждая из систем самостоятельно заботится о поддержке данных в корректном состоянии, что является довольно сложно задачей

Управляемый прерываниями

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

Устойчивый к изменениям (Protected Variations) - GRASP

Проблема	Как спроектировать систему так, чтобы изменение одних ее элементов не влияло на другие?
Решение	Идентифицировать точки возможных изменений или неустойчивости и распределить обязанности таким образом, чтобы обеспечить устойчивую работу системы.
Пример	Паттерн проектирования "Полиморфизм", см. является хорошей иллюстрацией данного метода. В данном случае точкой вариации или неустойчивости являются интерфейсы внешних систем. При добавлении интерфейса "IНалоговаяСистемаАдаптер" на основе принципа полиморфизма получается, что внутренние объекты смогут взаимодействовать с устойчивым интерфейсом, а детали взаимодействия с внешними системами будут скрыты в конкретных реализациях адаптеров.

Высокое зацепление (High Cohesion) - GRASP

Проблема	Необходимо обеспечить выполнение объектами разнородных функций.
Решение	Обеспечить распределение обязанностей с высоким зацеплением.
Пример	Если в примере для паттерна "Низкая связанность", см. на класс "Регистрация" возлагать все новые и новые системные функции, связанные с системными операциями, то данный класс будет слишком перегружен и будет обладать низкой степенью зацепления. Второй рисунок для примера Low Coupling обладает более высоким уровнем зацепления и низким уровнем связывания (он является более предпочтительным).
Преимущества	Классы с высокой степенью зацепления просты в поддержке и повторном использовании.
Недостатки	Иногда бывает неоправданно использовать высокое зацепление для распределенных серверных обьектов. В этом случае для обеспечения быстродействия необходимо создать несколько более крупных серверных обьектов со слабым зацеплением.

Взаимодействие "точка - точка"

Описание	У одной из систем есть интерфейс для доступа к ней активной системы. Данный паттерн применяется, в основном, при стихийной интеграции систем.
Недостатки	Данный метод взаимодействия соответствует требованиям активной системы, но непригоден для использования другой системой в качестве активной.

Взаимодействие "звезда" (интегрирующая среда)

Описание

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

Интегрирующая среда имеет универсальный интерфейс для доступа активных систем. Интегрирующая среда может использовать интерфейсы пассивных систем. Интегрирующая система включает в себя реализацию основных уровней интегрирующей среды: - базовый уровень интегрирующей среды (представляет собой ядро интегрирующей среды. Содержит платформу для исполнения сценариев транзакции, базовый функционал по взаимодействию приложений, службы протоколирования и мониторинга состояния интегрирующей среды); -уровень сценариев интеграции (графическая схема обмена сообщениями между системами, алгоритмы преобразования и маршрутизации этих сообщений); -транспортный уровень интегрирующей среды (физическая доставка сообщений между компонентами); -уровень адаптеров компонентов (взаимодействие с системой посредством ее API, генерация сообщений, передача сообщений базовому уровню посредством транспортного).

Загрузка по требованию (Lazy Load)

Задача

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

Решение

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

Данная работа представляет собой единый

Данная работа представляет собой единый словарь - справочник паттернов проектирования информационных систем, сформированный на основе обобщения и реструктурирования материала наиболее значительных монографий в этой области. Описания паттернов структурированы таким образом, чтобы обеспечить максимальное удобство в их освоении и использовании. Для этой цели выделены и систематически, на единых принципах описаны три группы паттернов проектирования, обсуждаемые в порядке возрастания "масштаба" решаемых задач.
Каждая из этих групп описывает паттерны для решения задач определенного уровня - от взаимодействия отдельных классов/обьектов системы до интеграции нескольких информационных систем в единое целое. В соответствии с этим в работе описаны паттерны проектирования взаимодействия обьектов информационных систем, архитектурные системные паттерны и паттерны интеграции. Следует подчеркнуть, что, по крайней мере в русскоязычной литературе, предложенная унифицированное обсуждение разнородных паттернов до сих пор отсутствовало.
Внутри вышеописанных групп паттернов проектирования проведена своя структуризация, упрощающая поиск и понимание назначения паттернов проектирования. Например, внутри группы паттернов проектирования классов/обьектов выделены паттерны для организации классов/обьектов в более крупные структуры, паттерны для распределения обязанностей между классами/объектами и паттерны для создания классов или обьектов. Аналогично, архитектурные паттерны разделены на структурные паттерны, служащие для разделения отдельной системы на несколько взаимодействующих подсистем и, кроме того, паттерны управления. для обеспечения взаимодействия этих подсистем.
Что же касается паттернов интеграции информационных систем, для них также были выделены структурные паттерны, кроме того, паттерны интеграции были сгруппированы по методу интеграции и по типу обмена данными между информационными системами.
В силу ограниченного объема данной работы, а, также из-за отсутствия в настоящее время достаточно хорошо проработанного материала по некотором тематикам в работе не обсуждаются некоторые виды паттернов. Это касается, например, паттернов, посвященных программной обработке ошибок, паттернов, описывающих типовые решения при организации распределенных вычислений, паттернов для систем реального времени и др.
Предлагаемый справочник будет полезен как начинающим, так и опытным проектировщикам информационных систем.

Заместитель (Proxy) или Суррогат (Surrogate) - GoF

Проблема

Необходимо управлять доступом к объекту, так чтобы создавать громоздкие объекты "по требованию".

Решение

Создать суррогат громоздкого объекта. "Заместитель" хранит ссылку, которая позволяет заместителю обратиться к реальному субъекту (объект класса "Заместитель" может обращаться к объекту класса "Субъект", если интерфейсы "РеальногоСубъекта" и "Субъекта" одинаковы). Поскольку интерфейс "РеальногоСубъекта" идентичен интерфейсу "Субъекта", так, что "Заместителя" можно подставить вместо "РеальногоСубъекта", контролирует доступ к "РеальномуСубъекту", может отвечать за создание или удаление "РеальногоСубъекта". "Субъект" определяет общий для "РеальногоСубъекта" и "Заместителя" интерфейс, так, что "Заместитель" может быть использован везде, где ожидается "РеальныйСубъект". При необходимости запросы могут быть переадресованы "Заместителем" "РеальномуСубъекту".
Заместитель (Proxy) или Суррогат (Surrogate) - GoF

Заместитель (Proxy) или Суррогат (Surrogate) - GoF

"Заместитель" может иметь и другие обязанности, а именно:

удаленный "Заместитель" может отвечать за кодирование запроса и его аргументов и отправку закодированного запроса реальному "Субъекту",

виртуальный "Заместитель" может кэшировать дополнительную информацию о реальном "Субъекте", чтобы отложить его создание,

защищающий "Заместитель" может проверять, имеет ли вызывающий объект необходимые для выполнения запроса права.

Организация: Управление - Планирование - Cтатистика