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

Оптимистическая автономная блокировка (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НалоговаяСистемаАдаптер" на основе принципа полиморфизма получается, что внутренние объекты смогут взаимодействовать с устойчивым интерфейсом, а детали взаимодействия с внешними системами будут скрыты в конкретных реализациях адаптеров.



Любой паттерн проектирования, используемый при


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

В настоящее время имеется обширная


В настоящее время имеется обширная литература, включающая несколько фундаментальных монографий, уделяющих внимание той или иной тематике. Однако, по крайней мере в русскоязычной литературе, до настоящего времени отсутствовал такой справочник основных паттернов проектирования. Предлагаемый справочник паттернов проектирования будет полезен как начинающим разработчикам в качестве вводного пособия, так и опытным проектировщикам как каталог типовых решений задач, часто встречающихся при разработке информационных систем. Основой предлагаемого систематизированного обзора послужил каталог, созданный мной для повседневной работы в качестве постановщика.
Паттерны проектирования, собранные в данном справочнике, разделены на три большие группы:
паттерны проектирования распределения обязанностей и взаимодействия отдельных классов или обьектов информационных систем; архитектурные паттерны; паттерны интегрирования информационных систем.
Хотя данное разделение, по - видимому, подразумевается профессионалами в области проектирования, мне нигде не встречалось явное систематическое обсуждение данной классификации. Существуют монографии, посвященные каждой отдельной группе паттернов, но нет их унифицированного рассмотрения на единых принципах.
Что касается вышеперечисленных групп паттернов, внутри каждой из них проведена дополнительная классификация. Проведено обобщение и в ряде случаев реструктурирование паттернов проектирования, описанных в различных монографиях, особенно это касается архитектурных паттернов, что делает данную классификацию до определенной степени оригинальной. Для простоты восприятия, мной предложено оформление описаний паттернов проектирования в виде таблиц, кроме того, имеется приложение со словарем терминов. При работе над словарем, многие разрозненные определения были подвергнуты корректировке, что позволило сделать систематическое изложение логически непротиворечивым.
В данную работу не включено описание элементов UML, использованных при построении диаграмм для иллюстрации паттернов проектирования.Всеобъемлющее описание может быть найдено в работе . Сами UML диаграммы построены в Rational Rose.

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


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



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


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



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


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

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



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


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



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


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

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


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

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

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