Pequeña charla sobre patrones de diseño (9) -Patrón de método de fábrica

Introducción a la columna

Dirección de columna

enlace

Introducción a la columna

Principalmente analiza y resume uno por uno los 23 patrones de diseño comunes actualmente en el mercado, espero que los amigos interesados ​​puedan echarle un vistazo y se actualizará continuamente. Espero que puedan supervisarme y podamos aprender y progresar juntos, vamos todos.

Patrón de método de fábrica

El patrón del método de fábrica es un patrón de diseño creacional que define una interfaz para crear objetos, pero depende de la subclase decidir qué clase crear una instancia. El patrón del método de fábrica difiere la creación de instancias de objetos a subclases.

Clasificación de roles

Producto abstracto

Define la interfaz del producto y es la clase principal común o interfaz de la clase de producto específica.

Producto de hormigón

Una clase concreta que implementa la interfaz abstracta del producto.

Fábrica abstracta

Define la interfaz para crear productos, incluido uno o más métodos abstractos para crear productos.

Fábrica de hormigón

Implementa la interfaz de fábrica abstracta y es responsable de crear instancias de productos específicos.

Idea principal

Al separar la creación y el uso de objetos, el cliente crea objetos llamando a métodos de fábrica en lugar de crear instancias directas de productos específicos. La ventaja de esto es que el cliente solo necesita conocer la existencia de productos abstractos y fábricas abstractas sin preocuparse por los detalles de productos específicos. Cuando necesite crear diferentes tipos de productos, solo necesita implementar los productos específicos correspondientes y las fábricas específicas sin modificar el código del cliente.

Implementación de código Java:

Supongamos que hay una fábrica de automóviles que puede producir diferentes tipos de automóviles, incluidos automóviles y SUV. Primero defina una clase de automóvil abstracta (AbstractProduct):

public abstract class Car {
    
    
    public abstract void drive();
}

Luego defina la clase de automóvil específica (ConcreteProduct1) y la clase SUV (ConcreteProduct2), que heredan de la clase de automóvil abstracta:

public class SedanCar extends Car {
    
    
    @Override
    public void drive() {
    
    
        System.out.println("Driving sedan car...");
    }
}

public class SUV extends Car {
    
    
    @Override
    public void drive() {
    
    
        System.out.println("Driving SUV...");
    }
}

A continuación, defina la clase abstracta de fábrica de automóviles (AbstractFactory), que contiene un método abstracto para crear automóviles:

public abstract class CarFactory {
    
    
    public abstract Car createCar();
}

Luego defina la clase de fábrica de automóviles específica (ConcreteFactory1) y la clase de fábrica de SUV (ConcreteFactory2), que heredan de la clase de fábrica de automóviles abstracta:

public class SedanCarFactory extends CarFactory {
    
    
    @Override
    public Car createCar() {
    
    
        return new SedanCar();
    }
}

public class SUVFactory extends CarFactory {
    
    
    @Override
    public Car createCar() {
    
    
        return new SUV();
    }
}

Finalmente, use el método de fábrica en el código del cliente para crear el objeto del automóvil:

public class Client {
    
    
    public static void main(String[] args) {
    
    
        CarFactory factory1 = new SedanCarFactory();
        Car sedanCar = factory1.createCar();
        sedanCar.drive();
        
        CarFactory factory2 = new SUVFactory();
        Car suv = factory2.createCar();
        suv.drive();
    }
}

El resultado de salida es

Driving sedan car...
Driving SUV...

analizar

A través del patrón del método de fábrica, el código del cliente solo necesita interactuar con el producto abstracto y la fábrica abstracta sin preocuparse por el proceso de creación del producto específico. Cuando necesite agregar otros tipos de automóviles, solo necesita implementar los productos específicos correspondientes y las fábricas específicas sin modificar el código del cliente, logrando escalabilidad y mantenibilidad del código.

Análisis de ventajas y desventajas

ventaja

Cumplir con el principio de apertura y cierre.

El patrón del método de fábrica hace que el sistema sea más escalable al introducir los conceptos de fábrica abstracta y fábrica concreta. Cuando necesite agregar un nuevo producto, solo necesita agregar el producto específico correspondiente y la fábrica específica, sin modificar el código existente, lo cual es consistente con el principio de apertura y cierre.

Encapsula el proceso de creación de objetos.

El cliente solo debe preocuparse por los productos abstractos y las fábricas abstractas, y no necesita preocuparse por el proceso de creación de productos específicos. El proceso de creación de productos específicos se encapsula en fábricas específicas, lo que hace que el código del cliente sea más conciso y legible.

Reduce el acoplamiento entre clientes y productos específicos.

El cliente sólo confía en productos abstractos y fábricas abstractas, no en productos específicos. Esto puede desacoplar el código del cliente del producto específico y mejorar la flexibilidad y la capacidad de mantenimiento del código.

Las clases de fábrica específicas se pueden especificar dinámicamente a través de archivos de configuración, etc.

El patrón del método de fábrica puede especificar dinámicamente clases de fábrica específicas a través de archivos de configuración, reflexión, etc., logrando así un método de creación de objetos más flexible.

defecto

Aumenta la complejidad del sistema.

La introducción de los conceptos de fábrica abstracta y fábrica concreta hace que la estructura del sistema sea más compleja. Si solo hay unos pocos productos en el sistema, utilizar el patrón del método de fábrica puede parecer demasiado complejo de mantener y comprender.

Aumentó la cantidad de código.

El patrón del método de fábrica requiere la definición de múltiples clases, como productos abstractos, productos concretos, fábricas abstractas y fábricas concretas, lo que aumenta la cantidad de código. Para proyectos simples, usar el patrón del método de fábrica puede parecer redundante.

El cliente necesita conocer la clase de fábrica específica.

El cliente necesita conocer la existencia de la clase de fábrica específica, lo que aumenta la dependencia del cliente. Si la lógica de creación de una clase de fábrica específica cambia, el código del cliente también debe modificarse en consecuencia.