Шаблоны проектирования: Factory vs Factory method vs Abstract Factory

Все три типа Factory делают то же самое: они «умный конструктор».

Предположим, вы хотите создать два вида фруктов: Apple и Orange.

завод

Фабрика «исправлена», поскольку у вас есть только одна реализация без подclassа. В этом случае у вас будет такой class:

class FruitFactory { public Apple makeApple() { // Code for creating an Apple here. } public Orange makeOrange() { // Code for creating an orange here. } } 

Случай использования. Построение Apple или Orange слишком сложно обрабатывать в конструкторе.

Заводской метод

Фабричный метод обычно используется, когда у вас есть какая-то общая обработка в classе, но вы хотите изменить тот вид фруктов, который вы на самом деле используете. Так:

 abstract class FruitPicker { protected abstract Fruit makeFruit(); public void pickFruit() { private final Fruit f = makeFruit(); // The fruit we will work on..  } } 

… тогда вы можете повторно использовать общую функциональность в FruitPicker.pickFruit() путем реализации фабричного метода в подclassах:

 class OrangePicker extends FruitPicker { @Override protected Fruit makeFruit() { return new Orange(); } } 

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

Абстрактная фабрика обычно используется для таких вещей, как зависимость / страtagsя зависимости, когда вы хотите создать целые семейства объектов, которые должны быть «одного типа», и иметь некоторые общие базовые classы. Вот пример, связанный с фруктами. Пример использования здесь заключается в том, что мы хотим убедиться, что мы случайно не используем OrangePicker на Apple. До тех пор, пока мы получим наш Фрукты и Пиккер с той же фабрики, они будут соответствовать.

 interface PlantFactory { Plant makePlant(); Picker makePicker(); } public class AppleFactory implements PlantFactory { Plant makePlant() { return new Apple(); } Picker makePicker() { return new ApplePicker(); } } public class OrangeFactory implements PlantFactory { Plant makePlant() { return new Orange(); } Picker makePicker() { return new OrangePicker(); } } 

Factory – отдельный class Factory для создания сложного объекта.

Пример: class FruitFactory для создания объекта Fruit

 class FruitFactory{ public static Fruit getFruit(){...} } 

Фабричный метод. Вместо целого отдельного classа для фабрики просто добавьте один метод в этот class как фабрику.

Пример:

 Calendar.getInstance() (Java's Calendar) 

Абстрактный заводской метод – фабрика фабрики

Пример: Предположим, мы хотим построить завод для частей компьютера. Таким образом, существует несколько типов компьютеров, таких как Laptop, Desktop, Server.

Поэтому для каждого типа компилятора нам нужна фабрика. Таким образом, мы создаем один высокоуровневый завод фабрик, как показано ниже

 ComputerTypeAbstractFactory.getComputerPartFactory(String computerType) ---> This will return PartFactory which can be one of these ServerPartFactory, LaptopPartFactory, DesktopPartFactory. 

Теперь эти три себя снова являются фабриками. (Вы будете иметь дело с самим PartFactory, но под капотом будет отдельная реализация, основанная на том, что вы предоставили на абстрактной фабрике)

  Interface-> PartFactory. getComputerPart(String s), Implementations -> ServerPartFactory, LaptopPartFactory, DesktopPartFactory. Usage: new ComputerTypeAbstractFactory().getFactory(“Laptop”).getComputerPart(“RAM”) 

EDIT: отредактирован для обеспечения точных интерфейсов для Abstract Factory в соответствии с возражениями в комментариях.

1. Как эти три шаблона отличаются друг от друга?

Factory: создает объекты, не подвергая клиентскую логику создания экземпляра.

Factory Method: Определите интерфейс для создания объекта, но пусть подclassы решают, какой class необходимо создать. Метод Factory позволяет создать экземпляр classа для подclassов

Abstract Factory: предоставляет интерфейс для создания семейств связанных или зависимых объектов без указания их конкретных classов.

AbstractFactory использует композицию, чтобы делегировать ответственность за создание объекта другому classу, в то время как шаблон проектирования метода Factory использует наследование и полагается на производный class или подclass для создания объекта

2. Когда использовать какой?

Фабрика: клиенту просто нужен class, и он не заботится о том, какую конкретную реализацию он получает.

Фабричный метод: клиент не знает, какие конкретные classы он должен будет создавать во время выполнения, но просто хочет получить class, который будет выполнять эту работу.

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

Абстрактные classы Factory часто реализуются с использованием метода Factory. Фабричные методы обычно вызываются в шаблонных методах.

3. А также, если возможно, любые примеры java, связанные с этими шаблонами?

Заводские и FactoryMethod

Намерение:

Определите интерфейс для создания объекта, но пусть подclass определяет, какой class следует создавать. Factory Method позволяет кластеру отложить создание экземпляров подclassов.

Диаграмма UML :

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

ConcreteProduct: реализует интерфейс продукта

Создатель: объявляет заводский метод

ConcreateCreator: реализует метод Factory для возврата экземпляра ConcreteProduct

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

Фрагмент кода:

Заводской шаблон. Когда использовать заводские методы?

Сравнение с другими шаблонами создания:

1. Дизайн начинается с использования Factory Method (менее сложные, настраиваемые, подclassы размножаются) и эволюционирует в направлении Abstract Factory, Prototype или Builder (более гибкий, более сложный), поскольку разработчик обнаруживает, что требуется больше гибкости

2. Абстрактные classы Factory часто реализуются с помощью Factory Methods , но они также могут быть реализованы с использованием Prototype

Ссылки для дальнейшего чтения: Sourcemaking design-patterns

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

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

Теперь, если вы предполагаете добавить еще один веб-сайт в свой портфель, и вы считаете, что одно и то же kernel ​​будет использоваться, например, на веб-сайте, на котором работает автомобиль, который теперь ищет такси и делает платежи онлайн, вы можете использовать абстрактный завод в своем ядре. Таким образом, вы можете просто щелкнуть еще один завод кабин и автобаз.

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

Надеюсь, теперь это ясно. Изучите веб-сайт, снова учитывая этот пример, надеюсь, это поможет. И я очень надеюсь, что правильно представил шаблоны :).

 AbstractProductA, A1 and A2 both implementing the AbstractProductA AbstractProductB, B1 and B2 both implementing the AbstractProductB interface Factory { AbstractProductA getProductA(); //Factory Method - generate A1/A2 } 

Используя Factory Method, пользователь может создать A1 или A2 AbstractProductA.

 interface AbstractFactory { AbstractProductA getProductA(); //Factory Method AbstractProductB getProductB(); //Factory Method } 

Но абстрактная фабрика имеет более 1 заводского метода (например: 2 фабричных метода), используя эти заводские методы, создаст набор объектов / связанных объектов. Используя абстрактную фабрику, пользователь может создавать объекты A1, B1 AbstractProductA, AbstractProductB