Абстрактное использование фабричного шаблона проектирования

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

Абстрактная фабрика имеет смысл, когда вам нужно создавать разные продукты одного семейства, не зная семейства (Volvo или Audi).

interface Car {}
interface Engine {}
interface Gear {}

interface ICarFactory {
    Car createCar();
    Engine createEngine();
    Gear createGear();
}

class AudiCar implements Car {}
class AudiEngine implements Engine {}
class AudiGear implements Gear {}

class AudiFactory implements ICarFactory {
    public Car createCar() { return new AudiCar(); }
    public Engine createEngine() { return new AudiEngine(); }
    public Gear createGear() { return new AudiGear(); }
}

Я считаю, что вы можете представить то же самое для Volvo.

Теперь предположим, что у нас есть класс, который строит Car, и ему все равно, Audi это или Volvo.

class CarBuilder {
    public static Car buildCar(ICarFactory factory) {
        Car car = factory.createCar();

        car.setEngine(factory.createEngine());
        car.setGear(factory.createGear());

        return car;
    }
}

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

В вашем примере:

• Factory Method Pattern - это шаблон для создания автомобиля (скрыть реализацию создания автомобиля)

• Абстрактный заводской шаблон - это шаблон для создания автомобильного завода (создание автомобильного завода, а не создание автомобиля, фокус на создании завода)

• Итак, вы можете подумать: паттерн Abstract Factory — это паттерн для создания Factory of Factory.

• Эти два шаблона предназначены для разных целей.

Абстрактный заводской шаблон (реализация с использованием интерфейса/абстракции) + шаблон IoC -> помочь вам решить, какой тип фабрики автомобилей используется во время выполнения, а не во время компиляции (шаблон метода фабрики не подходит для этих требований)

Вы очень хорошо поняли использование шаблона Factory: Factory позволяет создавать объекты, тип которых неизвестен во время компиляции (конечно, просто подкласс интерфейса). Теперь сделайте шаг вперед:

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

Вот когда на помощь приходит Абстрактная фабрика: Абстрактная фабрика — это фабрика фабрик, которая позволяет вам создавать фабрики, тип которых неизвестен во время компиляции: Итак, у вас будет

public interface AbstractCarFactory
{
    public CarFactory getCarFactory(String area);
}

... и вы сможете реализовать EuropeanCarFactory, AmericanCarFactory и т.д.

Другой пример, когда абстрактная фабрика полезна, — это когда у вас есть класс фабрики с параметрами в его конструкторе:

public CarFactory
{
    public CarFactory(boolean cheatingMotor) {...}
}

Создать один объект CarFactory с помощью динамического создания экземпляров (Class.forName("CarFactory").newInstance()) сложно, поэтому полезен еще один уровень факторизации вверх: абстрактная фабрика, которая решает, как создавать экземпляр CarFactory:

public interface AbstractCarFactory
{
    public CarFactory(boolean cheatingMotor);
}

public class MyAbstractCarFactory implements AbstractFactory
{
    public CarFactory(boolean cheatingMotor)
    {
        return new CarFactory(true);
    }
}

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

Подумайте об объекте java.sql.Connection. Для меня это абстрактная фабрика.

Он создает для вас Statement, CallableStatement и т. д.

Внутри это может быть OracleStatement или MySQLStatement.

Ваш клиентский код чист, и ему все равно, как он внутренне подключает сокет к серверу БД.

См. также Шаблоны проектирования: абстрактная фабрика и фабричный метод

О вашем исходном коде

Подумайте о реальном мире, автомобили GM не производятся на «Фабрике» Toyota или на каком-то заводе Generic :)

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

Если бы у Sun был конечный набор баз данных, с которыми нужно было бы иметь дело, они могли бы написать некоторые из них, если бы еще

Факт

1) Драйвер SQL не написан Sun 2) с помощью этого шаблона вы можете «внедрить» любой драйвер в свой код, не беспокоясь о том, как он работает, просто полагаясь на интерфейсы

просить клиента передавать "Ауди" на каждый звонок просто неразумно