Как добиться гибкости в шаблоне фабричного метода

Question

Ниже приведен пример абстрактного метода patter.

public interface Product {
    public void draw();     
    public void move();
}

public abstract class Creator {     
    public Product anOperation() {
        Product product = factoryMethod();
        return product;
    }

    public abstract Product factoryMethod();
}

public class ConcreateProduct1 implments Product {
    public void draw() {        
    }

    public void move():
    }
}

public class ConcreteCreator1 extends Creator {
    public Product factoryMethod() {
        return new ConcreateProduct1();
    }
}

public class Client {
    public static void main(String arg[]) {
        Creator creator = null;
        creator = new ConcreteCreator1();
        creator.anOperation().move();
    }
}

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

Кто-нибудь может мне объяснить, как мы достигаем гибкости, которой мы не можем достичь в следующем примере?

public class ConcreateProduct1 {
    public void draw() {        
    }

    public void move():
    }
}

public class Client {
    public static void main(String arg[]) {
        ConcreateProduct1 creator = new ConcreteCreator1();
        creator.move();
    }
}

Answer 1

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

Существует также еще одно интересное использование в сочетании с отражающим кодом. Представьте, что вы пишете класс Factory, не зная какой-либо конкретной реализации интерфейса. Наиболее распространенным примером является JDBC API. Из кода клиента вы получаете доступ к базе данных через URL, например <driverId>:<params>. Фабрика имеет HashMap<String, Class>, поэтому она может создать правильный тип на основе <driverId> с этим кодом

Class driverClass = drivers.get(driverId);
Constructor constructor = driverClass.getDeclaredConstructor();
return constructor.newInstance(params);

Производителю фабрики не нужно будет менять реализацию для добавления новых драйверов, поскольку они динамически регистрируются и создаются (в jdbc это происходит через Class.forName("com.example.Driver")). Обратите внимание, что это все еще кажется ненужной сложностью: зачем использовать фабрику только для того, чтобы получить класс класса, который вы должны знать ? В этом случае очевидным преимуществом является гибкость: имя драйвера - это строка, которую можно выводить (например, в файле конфигурации). Таким образом, конечный пользователь (не разработчик) может переключаться между драйверами без перекомпиляции приложения.

Answer 2

Как правило, фабрики полезны, когда:

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

Пример 1:

В вашем случае код клиента просто скажет

Product p = Creator.create(Some_Critera);

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

Пример 2:

Допустим, продукту нужно ввести 3 разных объекта. В этом случае каждое место, где вы делаете:

new SomeFancyProduct(dep1, dep2, dep3);

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

Однако каждый клиент должен иметь dep1 , dep2 и т. Д. Всякий раз, когда ему требуется SomeFancyProduct . Вместо этого только Creator может зависеть от этих 3 объектов, и клиенты могут быть независимыми, поэтому не имеют никакой связи между клиентами и dep1 , dep2 и т. Д. .