Передача аргументов определенному подклассу с помощью заводского метода

Question

Предположим, что у меня есть абстрактный класс Drink и фабричный метод, который выбирает тип напитка (Wine, Beer и т. Д.) Для создания во время выполнения.

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

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

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

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

Answer 1

Я бы создал различные методы перегрузки в вашем заводском классе.

public class DrinkFactory { 

    public static Drink CreateBeer(DrinkConfig config, string hops) { 
     return new Beer(config, hops); 
    } 

    public static Drink CreateWine(DrinkConfig config, string grapes, int temperature) { 
     return new Wine(config, grapes, temperature); 
    } 
} 

Edit:

Если это желательно, чтобы только один метод в классе Factory альтернативная реализация будет:

public enum DrinksEnum { 
    Beer, 
    Wine 
} 

public class DrinkFactory { 

    public static Drink CreateDrink(DrinksEnum drinkType, DrinkConfig config) { 
     switch(drinkType) { 
      case DrinksEnum.Beer: 
       return new Beer(config); 
      case DrinksEnum.Wine: 
       return new Wine(config); 
      default: 
       throw new ApplicationException("Drink type not recognised."); 
     } 
    } 
} 

Answer 2

Я соблазн обеспечить наивное решение, в котором ваш ингредиенты получены из базового класса «DrinkIngredients». Вам нужно будет соответствовать подклассу, который будет использоваться для конкретного напитка.

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

Answer 3

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

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

Если вам действительно нужно передать помощников во время выполнения из вызывающего кода, я предлагаю прочитать статью «Аргументы и результаты» (http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.7565), которая описывает общий шаблон для сортировки сложных аргументов. По существу, вы создали бы промежуточную коллекцию необходимых параметров и передали бы это фабрике.

Answer 4

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

Answer 5

В подобных случаях я обычно смотрю на другие решения вместо передачи в переменных.

Например, в вашем случае - WineFactory нуждающиеся в Сомелье, так что можно построить соответствующее вино -

Это отличный вариант использования для инъекций во время выполнения зависимостей. Рамка инъекций зависимостей в какой-либо форме могла бы сделать эту очень простую, понятную и справедливую работу без необходимости использования всех этих свойств.

Answer 6

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

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

Answer 7

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