Каталог паттернов проектирования
1 Порождающие:
1.1 Abstract Factory - Абстрактная фабрика - паттерн уровня объекта, данный паттерн предоставляет интерфейс, для создания семеств взаимосвязанных или взаимозависимых объектов, не специфицируя их конктных классов (не указывая клиенту о наличии их конкретных классов). Назначение - порождение семеств взаимодействующих продуктов.
1.2 Builder - Строитель - паттерн уровня объекта, данный паттерн отделяет (пошаговое) конструирование сложного объекта (продукта) от его представления (посылка запроса - вызов метода - это единственный способ заставить объект выполнить какую-либо операцию, а выполнение операции - единственный способ изменить внутреннее состояние объекта, имея ввиду два этих ограничения говорят, что два этих состояния объекта инкапсулированы - скрыты - к ним нельзя получить непосредственный доступ, т.е. представление объекта закрыто от внешней программы. Поэтому ассоциируют внутреннее состояние с представлением) так, что в результате одного и того же процесса конструирования могут получиться разные представления (если мы подставим директору плотника, он сделает деревянный дом, если каменщика, то каменный дом). Назначение - пошаговое построение сложных продуктов.
1.3 Factory Method - Фабричный метод - паттерн уровня класса, является базовым для остальных порождающих паттернов. Его задача не только описать процесс получения объектов, но ещё описать взаимодействие между базовым классом и производным классом. Если мы не знаем, какой паттерн использовать для порождения продукта, то следует использовать Фабричный метод.
1.4 Prototype - Прототип - паттерн уровня объекта - паттерн уровня объекта, задаёт виды (классы), создаваемых объектов - клонов, с помощью экземпляра прототипа (оригинала) и создаёт новые объекты путём копирования (клонирования) этого прототипа. Назначение - клонирование объектов. Применяется редко, т.к. необходимо переходить на прототипно ориентированное мышление. В .Net нашёл реализацию в виде интерфейса ICloneable и смомощью метода MemberwiseClone базового класса Object.
1.5 Singleton - Синглтон - паттерн уровня объекта, данный паттерн гарантирует, что у класса есть (может быть) только определённое (переменное) число экземпляров (один экземпляр - частный случай). Назначение - гарантирует наличие только одного экземпляра класса. В .Net данный паттерн имеет два выражение, через проверку на инициализацию и через статический класс для случаев, когда требуется лишь один экземпляр без наследников.
2 Структурные:
2.1 Adapter - Адаптер - имеет две разновидности, уровня класса и уровня объекта, данный паттерн преобразует интерфейс одного класса (Adaptee) в интерфейс другого (Target), который ожидают клиенты, адаптер обеспечивает совместную работу классов с несовместимыми интерфейсами, которые без него была бы невозможна. Назначение - адаптирует несовместимые интерфейсы. Также существует два вида адаптера: сменный и двусторонний. Сменный адаптер, это такой адаптер PluggableAdapter, в который встроен механизм адаптации интерфейсов нескольких адаптируемых классов AdapteeA, AdapteeB и т.д. Двусторонние адаптеры способны обеспечить возможность использовать адаптер TwoWayAdapter там, где мог использоваться Adaptee.
2.2 Bridge - Мост - паттерн уровня объекта, данный паттерн отделяет абстракцию от реализации так, чтобы и то и другое можно было изменять независимо друг от друга. Назначение - отделение абстракции от реализации.
2.3 Composite - Компоновщик - паттерн уровня объекта, данный паттерн компонует (собирает) объекты в древовидные структуры, для представления иерархии: часть - целое. Позволяет клиентам единообразно трактовать индивидуальные и составные объекты (для того, чтобы организовать рекурсиного обхода дерева и рекурсивной композиции (рекурсивного составления)). Деревья в данном контексте - это специальная структура данных, организованная по определённому принципу. Одна из целей паттерна компоновщик - избавить клиентов от обязанности знать работают ли они с листовым или составным уровнем, для достижения этой цели класс Component должен сделать как можно больше операций общими для классов Composite и Leaf. Обычно класс Component предоставляет для этих операций реализацию по умолчанию, а подклассы Composite и Leaf замещают их. Однако иногда эта цель вступает в конфликт с принципом проектирования иерархии классов, согласно которому класс должен определять (содержать), только логичные для всех его подклассов и его самого, операции. Класс Component поддерживает много операций не имеющих смысла для класса Leaf. Как же тогда предоставить для них реализацию по умолчанию? Иногда проявив изобретательность удаётся перенести в класс Component операцию, которая на первый взгляд имеет смысл только для составных объектов. Например, интерфейс для доступа к потомкам является фундаментальной частью класса Composite, но вовсе не обязательно для класса Leaf. Ответ: следует рассматривать Leaf, как ветку, у которой никогда не бывает потомков. И мы можем определить в классе Component операцию доступа к потомкам, как никогда не возвращающего потомков. Тогда подклассы Leaf могут использовать эту реализацию по умолчанию, а в подклассах Composite она будет переопределена, чтобы возвращать потомков. Объявление операции, для управления потомками: хотя в классе Composite реализованы операции Add и Remove для добавления и удаления потомков, для паттерна Composite важно в каких классах эти операции объявлены, надо ли объявлять их в классе Component и тем самым делать их доступными в Leaf или его следует объявить только в классе Composite и его подклассах. Решая этот вопрос мы должны выбирать между безопасностью и прозрачностью. Если определить интерфейс для управления потомками в корне иерархии классов, то мы добиваемся прозрачности, т.к. все компоненты удаётся трактовать единообразно. Однако расплачиваться приходится безопасностью, поскольку клиент мог выполнить бессмысленное действие, например добавить или удалить объект из листочка Leaf. Если управление потомками сделать частью класса Composite, то безопасность удаётся обеспечить, ведь любая попытка добавить или удалить объекты из листочков Leaf приведёт к ошибке, но тогда мы утрачиваем прозрачность, т.к. у листовых и составных объектов оказываются различные интерфейсы. В паттерне Composite придаётся особое значение прозрачности, а не безопасности. Назначение - построение "деревьев".
2.4 Decorator - Декоратор - паттерн уровня объекта, данный паттерн динамически (в ходе выполнения программы) добавляет объекту новые обязанности (состояния и поведение), (композиция, используемая в декораторе) является гибкой альтернативой рождению подклассов (наследованию) с целью расширения функциональности. Множество мелких объектов - минус и предостережение - при использовании в проекте паттерна Decorator не редко получается система составленная из большого числа мелких объектов, которые похожи друг на друга и различаются, только способом взаимосвязи, а не классом и не значениями своих внутренних переменных, хотя проектировщик разбирающийся в устройстве такой системы может легко настроить её, но изучать и отлаживать её очень тяжело. Назначение - добавляет объекту новое состояние и поведение.
2.5 Facade - Фасад - паттерн уровня объекта, данный паттерн предоставляет (клиенту) унифицированный (высокоуровневый) интерфейс (набор методов), вместо набора (низкоуровневых интерфейсов) некоторой подсистемы. Фасад определяет интерфейс более высокого уровня, который упрощает использование подсистемы. Используется, когда нужно предоставить простой интерфейс к сложной подсистеме, когда между клиентами и классами реализации абстракции существует много зависимостей, когда нужно разложить подсистему на отдельные слои. Фасад используется для определения точки входа в каждый слой системы. Классы подсистем ничего не знают о существовании Фасада, т.е. не хранят ссылок на него. Клиенты общаются с подсистемой, посылая запросы Фасаду, а уже он - Фасад - переадресует эти клиентские запросы подходящим объектам внутри подсистемы. Хотя основную работу выполняют именно объекты подсистемы, Фасаду возможно придётся преобразовать свой интерфейс в интерфейсы подсистем. Клиенты пользующиеся Фасадом не имеют прямого доступа к объектам подсистем. Но Фасад не препятствует приложениям (клиентам) напрямую обращаться к классам подсистемы, если это необходимо, таким образом есть выбор между простотой Фасада и общностью классов подсистем. Назначение - представляет высокоуровневый интерфейс для доступа к подсистеме.
2.6 Flyweight - Приспособленец - Легковес - паттерн уровня объекта, данный патерн ипользуется, когда в приложении используется большое число (одинаковых объектов со сходным состоянием, в данном случае также можно использовать статический класс) объектов, также если из-за большого числа объектов расходы на хранение их в памяти высоки, также когда возможно большую часть состояния вынести во вне. Многие группы объектов можно заменить относительно не большим количеством разделяемых объектов, поскольку внешнее состояние вынесено. Внутреннее состояние разделяемого объекта в данном патерне выделяется в виде статических полей в .Net, также когда приложение зависит от идентичности объекта. Состояние необходимое Приспособленцу для нормальной работы можно характеризовать, как внутреннее или внешнее. Внутренне состояние хранится в самом объекте ConcreteFlyweight, внешнее состояние хранится или вычисляется клиентами или находится в UnsharedConcreteFlyweight, который пользуется конкретным Flyweight. При использовании Приспособленцев не исключены затраты на передачу, поиск и вычисление внешнего состояния, особенно, если раньше оно хранилось, как внутреннее. Применимость паттерна в значительной степени зависит от того, на сколько легко идентифицировать внешнее состояние и вынести его за пределы разделяемых объектов. Паттерн Flyweight использует (организует) разделение объектов на разделяемые объекты и не разделяемые, для эффективной поддержки множества мелких (мелкие - это частный случай) объектов. Назначение - организует работу с разделяемыми объектами.
2.7 Proxy - Заместитель - Сурогат - паттерн уровня объекта, данный паттерн имеет 4 разновидности, он применим во всех случаях, когда возникает необходимость сослаться на объект более изошрённо (не прямо, а косвенноо), чем если использовать простую ссылку. Полезные случаи: 1. Удалённый заместитель - Посол - он представляет локального представителя, вместо объекта, находящегося в другом адресном пространстве (WCF); 2. Виртуальный заместитель - создаёт тяжёлые объекты по требованию. 3. Защищающий заместитель - контролирует доступ к исходному объекту, такие заместители полезны, когда для разных объектов определены различные права доступа (CRUD). 4. Умная ссылка - замена обычной ссылки - она позволяет выполнить дополнительные действия, при доступе к объекту и к типичным применениям такой ссылки можно отнести yeild, async await, Linq, lock. Объект Proxy является сурогатом другого объекта (Subject) и контролирует доступ к нему (к этому объекту). Виды сокращённо: удалённый заместитель, виртуальный заместитель, защищающий заместитель, умная ссылка. Proxy предоставляет интерфейс идентичный интерфейсу Subject так, что Proxy всегда может быть подставлен вместо реального субъекта (Subject). Назначение - предоставляет объект заместитель.
3 Поведенческие:
3.1 Chain of Responsibility - Цепочка обязанностей - паттерн уровня объекта, данный паттерн позволяет избежать привязки отправителя запроса клиента к его получателю, давая шанс обработать запрос несколькиим объектам, этот же паттерн связывает объекты получателей в цепочку и передаёт запрос вдоль этой цепочки, пока его не обработают. Одним из достоинств является саморегуляция и отсутствие необходимости в менеджере. Важной особенностью паттерна является то, что у запроса, только один обработчик реализует ответ, в отличии от обработки жизненного цикла страницы. Используется, когда есть более одного объекта, способного обработать запрос, причём настоящий обработчик заранее не известен и должен быть найден автоматически; когда мы хотим отправить запрос одному из нескольких объектов, не указывая явно какому именно, когда набор объектов способных обработать запрос должен задаваться динамически. Осуществляет ослабление связанности (упрощение системы). Данный паттерн освободждает объект от необходимости знать, кто конкретно обработает его запрос, отправителю и получателю ничего не известно друг о друге, а включённому в цепочку объекту о структуре этой цепочки. Таким образом цепочка обязанностей помогает упростить взаимосвязи между объектами, вместо того, чтобы хранить ссылки на все объекты, которые могут стать получателями запроса, объект (т.е. клиент) должен располагать информацией лишь о своём ближайшем приемнике. Минусом является то, что получение результата не гарантировано, поскольку у запроса нет явного получателя, то не и гарантии, что он вообще будет работать, он может достичь конца цепочки и пропасть, необработанным запрос может оказаться и в случае не правильной конфигурации цепочки. Назначение - создаёт цепочки из обработчиков запросов.