Этот код реализует «Заводской шаблон», заводские методы, оба или ничего?

Question

Хотя этот вопрос обсуждался много раз, я все еще нахожусь слишком смущенным.

У меня есть этот простой пример кода:

public class FruitFactory { 

    public static Apple getApple() { 
     return new Apple(); 
    } 

    public static Banana getBanana() { 
     return new Banana(); 
    } 

    public static Orange getOrange() { 
     return new Orange(); 
    } 
} 

• Какой Factoryтип этот код? и является ли это правильной записью factory methods?
• Определение фабрики картины: создать объект, не подвергая логику создания клиента

Если я разоблачить мой клиент некоторых сложностей создания вроде как на пример ниже, является его плохо заводская реализация?

public static Orange getOrange(String weight, String size,) { 
    return new Orange(weight, size); 
} 

Answer 1

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

функция на языке, который позволяет функции «верхнего уровня», может быть завод, а также:

public Orange growNewOrange(String weight, String size) { 
    /// ...traditionally not callers concern. 
} 

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

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

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

Немедленно полезный совет будет заключаться в создании кода создания в пакете Java или классе, где задание параметров созданного объекта выполняется для каждого объекта, в то время как логика создания фабричного состояния - например, размер повторно используемого объекта пул и т. д. - создается во время создания фабрики. Пулы объектов являются одним из примеров заводского шаблона на работе.

Answer 2

• Первый код - это шаблон Factory, потому что у вас есть только один класс без подкласса, переопределения и т. Д.

Если вы хотите использовать фабричный метод, чем писать (Banana наследуется от Fruit):

public abstract FruitFactory { 
    public abstract Fruit createFruit(); 
} 

public BananaFactory extends FruitFactory { 
    @Override 
    public Fruit createFruit() { 
     return new Banana(); 
    } 
} 

Реализация:

public static Orange getOrange(String weight, String size) { 
    return new Orange(weight, size); 
} 

также правильное применение на мой взгляд, потому что вы инкапсулировать логику создания, как описано в @amn.

Хорошая вещь в использовании метода static заключается в том, что вы можете сделать конструктор private, так что это возможно только для создания объектов с помощью метода.

Для лучшего понимания смотрите следующую ссылку: Цель patterns

Answer 3

фабричной модели является положить слой абстракции поверх создания объекта.

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

Это проблема с вашим текущим кодом, он не добавляет слой абстракции ни к чему. Вы просто инкапсулируете конструктор.

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

Edit:. Оригинальная Банда четыре описания

«Определить интерфейс для создания объекта, но пусть подклассы решить, какой класс инстанцировать Фабричный метод позволяет в классе Defer экземпляры он использует для подклассов. "

Это означает, что ваш код не является фабрикой, потому что вам нужно определить, что вам нужно.