Factory Шаблон, но с объектом Параметры

Ответ 1

Вы можете добавить параметры к методу (-ам) создателя вашего factory. Однако, если количество параметров становится выше (для меня это будет больше 2-3), и особенно если некоторые или все эти параметры являются необязательными с разумными значениями по умолчанию, вы можете рассмотреть возможность превращения factory в Builder.

Это может быть особенно полезно для пиццы, где у вас обычно есть одна и та же корка, только с разными (комбинациями) начинок. Строитель очень близко моделирует общий способ упорядочивания, например. "пицца с салями, помидорами, кукурузой и двойным сыром". OTOH для "предопределенных" пицц вы можете определить вспомогательные методы factory, например. createMargaritaPizza или createHawaiiPizza, которые затем внутренне используют построитель для создания пиццы с начинками, характерными для такого пиццы.

Ответ 2

Вам понадобится добавить еще один метод CreatePizza() для этого класса factory. И это будет означать, что пользователи factory не смогут создавать эти типы пиццы, если они специально не используют экземпляр класса HamAndMushroomPizzaFactory. Если у них просто есть ссылка PizzaFactory, они могут вызывать только версию без параметров и не смогут создавать ветчину и грибную пиццу в целом.

Ответ 3

Вы можете использовать отражение:

using System.Reflection;

// ...

public override IPizza CreatePizza(PizzaType pizzaType, params object[] parameters) {
            return (IPizza)
                   Activator.CreateInstance(
                        Assembly
                             .GetExecutingAssembly()
                             .GetType(pizzaType.ToString()),
                        parameters);
        }

Ответ 4

Вы можете передать новый параметр, например карту. И запросите свойства на каждом конкретном конструкторе. Тогда все методы будут иметь одну и ту же подпись. Однако при этом решении вызывающий объект конструктора должен знать конкретные свойства конструктора конкрета... (Сцепление)

Ответ 5

Прежде всего, мне кажется странным, что абстрактный класс PizzaFactory содержит абстрактный общий метод CreatePizza, который принимает параметр более конкретного типа ItalianPizzaFactory.PizzaType.

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

public struct PizzaDefinition
{
    public readonly string Tag; 
    public readonly string Name;
    public readonly string Description;
    public PizzaDefinition(string tag, string name, string description)
    {
        Tag = tag; Name = name; Description = description;
    }
}

public abstract class PizzaFactory
{
    public abstract IEnumerable<PizzaDefinition> GetMenu();
    public abstract IPizza CreatePizza(PizzaDefinition pizzaDefinition);
}


public class ItalianPizzaFactory : PizzaFactory
{
    public enum PizzaType
    {
        HamMushroom,
        Deluxe,
        Hawaiian
    }    

    public override IEnumerable<PizzaDefinition> GetMenu()
    {
        return new PizzaDefinition[] {
            new PizzaDefinition("hm:mushroom1,cheese3", "Ham&Mushroom 1", "blabla"),
            new PizzaDefinition("hm:mushroom2,cheese1", "Ham&Mushroom 2", "blabla"),
            new PizzaDefinition("dx", "Deluxe", "blabla"),
            new PizzaDefinition("Hawaian:shrimps,caramel", "Hawaian", "blabla")
        };
    }

    private PizzaType ParseTag(string tag, out object[] options){...}

    public override IPizza CreatePizza(PizzaDefinition pizzaDefinition)
    {
        object[] options;
        switch (ParseTag(pizzaDefinition.Tag, out options))
        {
            case PizzaType.HamMushroom:
                return new HamAndMushroomPizza(options);
            case PizzaType.Hawaiian:
                return new HawaiianPizza();
            default:
                throw new ArgumentException("The pizza" + pizzaDefinition.Name + " is not on the menu.");
        }
    }
}

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

Ответ 6

Вы можете попробовать что-то вроде этого:

interface IPizza
{
}

class Pizza1 : IPizza
{
  public Pizza1(Pizza1Parameter p)
  {
  }
}

class Pizza2 : IPizza
{
  public Pizza2(Pizza2Parameter p)
  {
  }
}

interface IPizzaParameter
{
  object Type { get; set; }
}

class Pizza1Parameter : IPizzaParameter
{
  public object Type { get; set; }
}

class Pizza2Parameter : IPizzaParameter
{
  public object Type { get; set; }
}

static class PizzaFactory
{
  public enum PizzaType
  {
    Pizza1,
    Pizza2,
  }

  public static IPizza CreatePizza(PizzaType type, IPizzaParameter param)
  {
    switch (type)
    {
      case PizzaType.Pizza1:
        return new Pizza1(param as Pizza1Parameter);
      case PizzaType.Pizza2:
        return new Pizza2(param as Pizza2Parameter);
    }

    throw new ArgumentException();
  }
}

class Program
{
  static void Main()
  {
    var param1 = new Pizza1Parameter();
    var p1 = PizzaFactory.CreatePizza(PizzaFactory.PizzaType.Pizza1, param1);
  }
}

Концепция IMHO factory с конкретными параметрами реализации выглядит неправильно.

Ответ 7

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

Кроме того, когда параметры "необходимы", я также думаю, что Builder теряет свое очарование.

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