Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Кочелаев_сессия.docx
Скачиваний:
3
Добавлен:
08.08.2019
Размер:
128.03 Кб
Скачать
  1. Паттерн Фабрика

Абстрактная фабрика(англ. Abstract factory) —порождающий шаблон проектирования, позволяющий изменять поведение системы, варьируя создаваемые объекты, при этом сохраняя интерфейсы. Он позволяет создавать целые группы взаимосвязанных объектов, которые, будучи созданными одной фабрикой, реализуют общее поведение. Шаблон реализуется созданием абстрактного класса Factory, который представляет собой интерфейс для создания компонентов системы (например, для оконного интерфейса он может создавать окна и кнопки). Затем пишутся наследующиеся от него классы, реализующие этот интерфейс.

Цель

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

Плюсы

  • изолирует конкретные классы;

  • упрощает замену семейств продуктов;

  • гарантирует сочетаемость продуктов.

Минусы

  • сложно добавить поддержку нового вида продуктов.

Применимость

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

  • Входящие в семейство взаимосвязанные объекты должны использоваться вместе и вам необходимо обеспечить выполнение этого ограничения.

  • Система должна конфигурироваться одним из семейств составляющих ее объектов.

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

  1. Паттерн строитель

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

Данный шаблон используется в случае, если:

  • процесс создания объекта можно разделить на части (шаги);

  • (и) алгоритм этого процесса не должен зависеть от того, из каких частей состоит объект;

  • (и) конструирование должно обеспечивать возможность создавать различные объекты.

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

Обратите внимание:

  • данный шаблон не скрывает реализацию порождаемых объектов, а создает то, что требуется;

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

Шаблон Строитель включает двух участников процесса:

  • Строитель (Builder) – предоставляет методы для сборки частей объекта, при необходимости преобразовывает исходные данные в нужный вид, создает и выдает объект;

  • Распорядитель (Director) – определяет стратегию сборки: собирает данные и определяет порядок вызовов методов Строителя.

Может возникнуть вопрос: если можно напрямую вызывать методы Строителя, то зачем нужен Распорядитель? Его задача – сокрытие стратегии сборки. Это позволит, при необходимости, модифицировать или даже полностью менять ее, не затрагивая остальной код.

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

Схожие шаблоны и их отличия

Строитель

Фабричный метод

Абстрактная фабрика

Создает в несколько шагов один сложный (составной) объект.

Порождает один объект с определенным интерфейсом.

Порождает семейство объектов с определенными интерфейсами.

Интерфейс строителя, реализуемый классами, и класс для управления процессом.

Метод класса, который переопределяется потомками.

Интерфейс, реализуемый классами.

Скрывает процесс создания объекта, порождает требуемую реализацию.

Скрывает реализацию объекта.

Скрывает реализацию семейства объектов.

Реализация шаблона в общем виде

  • определяем шаги конструирования сложного объекта, и на их основе разрабатываем интерфейс Строителя IBuilder;

  • если планируется несколько стратегий сборки, то создаем интерфейс Распорядителя IDirector;

  • разрабатываем класс Распорядителя MyDirector (реализующий IDirector), работающий со Строителями через интерфейс IBuilder;

  • создаем класс Строителя MyBuilder, реализующий интерфейс IBuilder и метод получения результата;

  • в клиентском коде экземпляру MyDirector передаем интерфейс IBuilder экземпляра MyBuilder;

  • запускаем процесс сборки, вызвав метод Распорядителя;

  • получаем созданный экземпляр MyProduct у используемой реализации Строителя MyBuilder.

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

Prototype

Назначение

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

Проще говоря, это паттерн создания объекта через клонирование другого объекта вместо создания через конструктор.

Применимость

Паттерн используется чтобы:

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

  • избежать наследования создателя объекта (object creator) в клиентском приложении, как это делает паттерн abstract factory.

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

  • инстанцируемые классы определяются во время выполнения, например с помощью динамической загрузки;

  • для того чтобы избежать построения иерархий классов или фабрик, параллельных иерархии классов продуктов;

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