Spring: diferencia entre la inyección de dependencia y el patrón de fábrica

Dependency Injection y Factory Pattern son casi similares en el sentido de que ambos siguen el enfoque de programación basado en interfaz y crean la instancia de las clases.

A. Patrón de fábrica

En Factory Pattern , la clase de cliente sigue siendo responsable de obtener la instancia de los productos mediante el método class getInstance() de la clase de fábrica, lo que significa que la clase de cliente está directamente acoplada con la clase de fábrica y no se puede probar la unidad sin la clase de fábrica.

Implementación: en este ejemplo, veremos la diferencia entre Factory Pattern y DI con la ayuda de la aplicación ExpenseTracker. En esta aplicación, tenemos una clase dependiente ExpenseTracker que depende de la clase ExpenseCalculator. Aquí usaremos tanto Factory Pattern como Dependency Injection para comprender la diferencia entre ellos.

Ejemplo:

Java

// Java Program to Illustrate Factory Pattern
 
// Dependent class
public class ExpenseTracker {
 
    // Getting instance of ExpenseCalculator class
    // using Factory class method
    private ExpenseCalculator expenseCal
        = ExpenseCalculatorFactory.getInstance();
 
    // Method
    public void add(Transaction transaction)
    {
 
        // Returns the expense amount
        // of ExpenseCalculator class
        int expense
            = expenseCal.getTransactionAmount(transaction);
        add(expense);
    }
}

Explicación del código: en el ejemplo anterior, podemos ver que nuestra clase dependiente ExpenseTracker está directamente acoplada con ExpenseCalculatorFactory , ya que está llamando al método estático getInstance() de la clase ExpenseCalculatorFactory para satisfacer su dependencia. Si queremos probar la clase ExpenseTracker, debemos tener la clase ExpenseCalculatorFactory que no es adecuada para la prueba unitaria de la clase ExpenseTracker y hace que la prueba unitaria sea más difícil.

Por otro lado, si usaremos DI, las dependencias se agregan mediante el marco Spring o el contenedor DI a medida que invertimos las responsabilidades de adquisición de dependencias. Esto hará que el contenedor IOC sea responsable de inyectar las dependencias en lugar de la clase dependiente y convertirá cualquier cliente o clase dependiente en una clase POJO.

B. Inyección de dependencia

En el caso de Inyección de dependencia (DI), el cliente no sabe cómo se crean y administran las dependencias. La clase de cliente solo conoce las dependencias y la mayoría de las dependencias son inyectadas por el contenedor IOC . Por ejemplo, la clase Bean existe sin ninguna dependencia codificada y los contenedores IOC como Spring Framework los inyectan.

Ejemplo:

Java

// Java Program to Illustrate Dependency Injection
 
// Dependent class ExpenseTracker
public class ExpenseTracker {
 
    // Class data member
    private ExpenseCalculator expenseCal;
 
    // Constructor
    // Dependencies are injected
    // using Constructor Dependency Injection
    public ExpenseTracker(
        ExpenseCalculator expenseCalculator)
    {
 
        // This keyword refers to current instance itself
        this.expenseCal = expenseCalculator;
    }
 
    // Method
    public void add(Transaction transaction)
    {
        int expense
            = expenseCal.getTransactionAmount(transaction);
        add(expense);
    }
 
    // Dependencies are injected
    // using Setter Dependency Injection
    public void setExpenseCalculator(
        ExpenseCalculator expenseCalculator)
    {
        this.expenseCal = expenseCalculator;
    }
}

Explicación del Código: Podemos ver que la dependencia de ExpenseCalculator se inyecta en la clase ExpenseTracker usando el constructor de la clase, esto se llama Inyección de Dependencia del Constructor . Además, podemos inyectar la dependencia usando los métodos Setter que también podemos ver en el código anterior, se llama Setter Dependency Injection .

Diferencia entre inyección de dependencia y patrón de fábrica

Inyección de dependencia

Patrón de fábrica

DI solo es consciente de las dependencias. No sabe nada sobre el contenedor o la fábrica. Agrega acoplamiento entre objetos, fábrica y dependencia. Requiere tanto un objeto dependiente como un objeto de fábrica para funcionar correctamente.
DI facilita las pruebas unitarias. No requiere código repetitivo. El patrón de fábrica requiere el objeto que desea probar, el objeto de fábrica y el objeto dependiente.
DI es más flexible que los patrones de fábrica. También brinda la posibilidad de cambiar diferentes marcos DI como Spring IOC y Google Guice. No es tan flexible como la inyección de dependencia.
DI requiere un contenedor y una configuración para inyectar dependencias. El patrón de fábrica no requiere estos pasos de configuración.
Debido al menor acoplamiento, el resultado de DI es mucho más limpio. La clase de cliente se parece a la clase POJO. En el caso del patrón Factory, la clase de cliente no está limpia como en DI.

Publicación traducida automáticamente

Artículo escrito por ankur035 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *