(Фабричный метод) Factory Method или Виртуальный конструктор (Virtual Constructor) - GoF

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

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

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

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

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

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

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

Gof - Design Patterns: Elements of Reusable Object-Oriented Software (Приемы объектно-ориентированного проектирования. Паттерны проектирования) — книга 1994 года об инженерии программного обеспечения, описывающая решения некоторых частых проблем в проектировании ПО. Авторы книги: Эрих Гамма (Erich Gamma), Ричард Хелм (Richard Helm), Ральф Джонсон (Ralph Johnson), Джон Влиссидс (John Vlissides). Коллектив авторов также известен как «Банда четырёх», Gang of Four^[1], GoF. Описаны: Порождающие шаблоны проектирования Структурные шаблоны проектирования

Поведенческие шаблоны проектирования

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

В книге Крейга Лармана (Craig Larman) «Применение UML и шаблонов проектирования»^[1] описано 9 таких образцов. Каждый из них помогает решить некоторую проблему, возникающую при объектно-ориентированном анализе, и которая возникает практически в любом проекте по разработке программного обеспечения. Таким образом, GRASP-паттерны — это хорошо документированные, стандартизированные и проверенные временем принципы объектно-ориентированного анализа, а не попытка привнести что-то принципиально новое.

Шаблоны J2EE — Набор шаблонов проектирования, описывающих архитектуру серверной платформы для задач средних и крупных предприятий.

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

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

Элементы описания паттерна (паттерн характеризуется):

- имя (название) – отражает его смысл и решаемую задачу

- задача – описание того, когда применяется паттерн – формулируется решаемая проблема и перечесляются условия, когда эффективно применение паттерна - решение – описание элементов дизайна, отношений между элементами, описание функций элементов в рамках решения абстрактной задачи проектирования

- результат применения паттерна – следствия, варианты, компромиссы – указывают достоинства и недостатки, в частности влияние на возможности повторного использования кода, на расширяемость и переносимость системы

Классификация шаблонов

по ЖЦ:

-анализа -планирования -разработки -тестирования Группы: -GRASP -Gof -J2EE

-Microsoft

Функциональное назначение:

-основные фундаментальные -шаблоны разделения обязанностей

-порождающие

-поведенческие

-структурные

-MVC -Enterprise

-др(аналитические, коммуникационные, организационные) Уровень:

-класс

-кооперация

-подсистема

-система-надсистема

Шаблоны распределения обязанностей - позволяют применить общую методику распределения сфер ответственности классов

Виды обязанностей

1) Знание

-информация об инкапсулированных данных (о себе)

-о связанных объектах

-о следствиях и вычисляемых значениях

2) Действие

-выполнение действий самим объектом

- выполнение вычислений

- инициирование действий других объектов

- управление действиями других объектов

Реализация обязанностей осуществлена в методах, а распределение обязанностей отображается на взаимодействии объектов

Обязанности оформляются в виде произвольно составленного текста. Как правило, каждая обязанность излагается в одном предложении или, на крайний случай, в коротком абзаце.