фабричный метод шаблон проектирования

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

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

например WebRequest.Создать("http://www.example.com") вернет мне HttpWebRequest, но WebRequest.Создать("ftp://www.example.com") вернет мне FtpWebRequest, потому что оба имеют разные протоколы, которые реализованы разными классами, но открытый интерфейс одинаков, поэтому это решение не должно приниматься потребителем моего API.

Product Make () сделает правильный тип (подкласс) продукта на основе определенных условий и "отложит" фактический экземпляр до конкретных продуктов.

(код psuedo)

public class Product
{
    public static Product Make()
    {
        switch(day_of_week)
        {
           case Monday: return new Honey(1.1);
           case Wednesday: return new Milk(3.6);
           case Thurday: return new Meat(0.5);
           case Friday: return new Vegetable(1.3);
           case Saturday: return new Vegetable(2.3); // more expensive on saturday, only factory need to know
           default: return null; // off day!
        }
    }

    // returns price based on underlying product type and hidden/auto conditions (days of week)
    public virtual void GetPrice() { return Price; }

    // sometimes a factory can accept a product type enum
    // From API POV, this is easier at a glance to know avaliable types.
    pubic enum Type { Milk, Honey, Meat, Vegetable };

    public static Product Make(Type, Day)
    {
        // create the specified type for the specified day.
    }
}

public class Honey : Product { Price = arg; }
public class Milk : Product { Price = arg; }
public class Meat : Product { Price = arg; }
public class Vegetable : Product { Price = arg; }

Factory скрывает необходимые условные данные для построения различных типов продуктов. Во-вторых, IMHO, с точки зрения пользователя API, обычно легче увидеть, какие типы продуктов есть (обычно из перечисления), и легче создать их с одной точки создание.

просто и коротко:

на завод, проверяется, какой" подкласс " запрашивается для создания экземпляра so "let the subclasses decide which class to instantiate"
(вы используете условные операторы в Заводском классе, где должно быть принято решение.)

"define an interface or abstract class for creating an object". очевидно, что вы храните объект в ссылке интерфейса, и клиент не знает, какой объект конкретного класса возвращается. (таким образом, вы определили интерфейс для создания объекта).

Я могу только предположить, что он имеет в виду это:

class Product; //this is what the Factory Method should return
class Box : Product;

class Creator {
    public:
        Creator()   //ctor
        { //... }

        virtual Product* make(//args) = 0;
};

class BoxCreator{
    public:
        BoxCreator()
        {}
        virtual Product* make()
        {}
};

Creator* pCreator = new BoxCreator;
Product* pProduct = pCreator->make(); //will create a new box

однако это не стандартный способ создания фабрики.

предоставление таких примеров в псевдо-коде немного запутанно, шаблон очень зависит от языка. Ваш пример выглядит как в C++, но он недействителен в C++, потому что make возвращает Product по значению. Это полностью противоречит главной цели Factory - для возврата ссылки (указателя в случае C++) на базовый класс. Некоторые ответы принимают это как C# или Java (я думаю), когда другие как c++.

Factory шаблон опирается на полиморфизм. Ключевым моментом является возврат ссылки на base Product класса. Дети Factory создаст экземпляры конкретных классов.

У меня такая же путаница "пусть подклассы решают, какой класс создавать" - потому что в реализации Заводского метода с использованием new Для создания объекта " - я ссылаюсь на первую книгу шаблонов дизайна, в которой четко указано об этом следующим образом - "Как и в официальном определении, вы часто услышите, что разработчики говорят, что пусть подкласс решает, какой класс создавать .Они говорят "решает" не потому, что шаблон позволяет подклассу самим решать время выполнения, а потому, что создатель класс пишется без знания фактического продукта, который будет создан, что определяется исключительно выбором подкласса, который используется "