A medida que avanzamos en un proyecto, perdidos en bloques if-else, luchando con condiciones complejas y código repetitivo, buscamos una solución. Pero ¿por qué deberíamos quedarnos atrapados en bloques si-si no? En este artículo, descubramos la manera de deshacernos de la confusión if-else junto con los patrones Strategy y Factory.

Problema: confusión entre si y lo contrario

Supongamos que está desarrollando una aplicación de comercio electrónico y necesita admitir diferentes métodos de pago, como tarjeta de crédito, tarjeta de débito y criptomonedas. Comienzas con bloques if-else para procesar pagos:

public class PaymentService {

    public void processPayment(String paymentType) {
        if (paymentType.equals("CREDIT_CARD")) {
            System.out.println("Processing credit card payment...");
        } else if (paymentType.equals("DEBIT_CARD")) {
            System.out.println("Processing debit card payment...");
        } else if (paymentType.equals("CRYPTO")) {
            System.out.println("Processing crypto payment...");
        } else {
            throw new IllegalArgumentException("Invalid payment type");
        }
    }
}

Si bien puede parecer simple al principio, a medida que los métodos de pago aumentan, también lo hará la complejidad if-else. Un nuevo método de pago significa agregar una nueva condición. El resultado es un montón de código difícil de gestionar. Y este método es contrario al principio abierto-cerrado.

Pero podemos usar los patrones Estrategia y Fábrica para resolver este problema.

Primero, creemos una enumeración:

public enum PaymentType {
    CREDIT_CARD,
    DEBIT_CARD,
    CRYPTO
}

Solución: Limpieza con patrón estratégico

public interface PaymentStrategy {
    void pay(PaymentRequest request);
}

public class CreditCardPayment implements PaymentStrategy {
    @Override
    public void pay(PaymentRequest request) {
        System.out.println("Processing $type payment".replace("$type", String.valueOf(request.getPaymentType())));
    }
}

public class DebitCardPayment implements PaymentStrategy {
    @Override
    public void pay(PaymentRequest request) {
        System.out.println("Processing $type payment".replace("$type", String.valueOf(request.getPaymentType())));
    }
}

public class CryptoPayment implements PaymentStrategy {
    @Override
    public void pay(PaymentRequest request) {
        System.out.println("Processing $type payment".replace("$type", String.valueOf(request.getPaymentType())));
    }
}

En esta etapa, se implementa una estrategia separada para cada método de pago desde una interfaz común. Ahora, con Factory Pattern, decidiremos qué estrategia elegir.

Paso 2: elegir la estrategia con el patrón de fábrica

En este paso, podemos hacer que Factory Pattern sea más limpio y optimizado con EnumMap.

public class PaymentFactory {
    private static final Map strategies = new EnumMap(PaymentType.class);

    static {
        strategies.put(PaymentType.CREDIT_CARD, new CreditCardPayment());
        strategies.put(PaymentType.DEBIT_CARD, new DebitCardPayment());
        strategies.put(PaymentType.CRYPTO, new CryptoPayment());
    }

    public static PaymentStrategy getPaymentStrategy(PaymentType paymentType) {
        PaymentStrategy strategy = strategies.get(paymentType);

        if (Objects.isNull(strategy))
            throw new IllegalArgumentException("Strategy not found");

        return strategy;
    }
}

Último paso: reorganización de la clase de servicio

Ahora, usemos lo que hemos hecho.

public class PaymentService {

    public void processPayment(PaymentRequest request) {
        // Don't forget to check objects if null!
        if (Objects.isNull(request) || Objects.isNull(request.getPaymentType())
            throw new IllegalArgumentException("Request can not be null!");
        PaymentStrategy strategy = PaymentFactory.getPaymentStrategy(request.getPaymentType());

        strategy.pay(request);
    }
}

Tal como están las cosas, no necesitamos ningún bloque if-else para el procesamiento de pagos. Gracias a Strategy y Factory Patterns, nuestro código es más limpio, modular y extensible.

¿Por qué deberíamos utilizar estos patrones?

1. Extensibilidad: Agregar un nuevo método de pago solo requiere una nueva clase y unas pocas líneas de código.
2. Legibilidad: Al utilizar estrategias y fábrica en lugar de bloques if-else, hace que su código sea más comprensible y manejable.
3. Mantenibilidad: Con la estrategia y el patrón de fábrica, se pueden realizar cambios en el código sin afectar otras partes del código.

Conclusión: de la confusión a la claridad

Si estás trabajando en un proyecto en crecimiento, no deberías usar bloques if-else. Los patrones de estrategia y fábrica son soluciones perfectas para hacer que su código sea más limpio, modular y fácil de mantener.

Como puede ver en este artículo, el uso de patrones de diseño en lugar de bloques if-else para administrar las transacciones de pago hace que el proyecto sea más desarrollable y mejora la legibilidad del código. Pruebe estos patrones en su próximo proyecto en lugar de usar bloques if-else.

...

¡Gracias por leer mi artículo! Si tiene alguna pregunta, comentario o idea que le gustaría compartir, me encantaría escucharla en los comentarios.

Puedes seguirme en dev.to para obtener más información sobre este tema y mis otras publicaciones.

¿¿Gracias??

Para seguirme en LinkedIn: https://www.linkedin.com/in/tamerardal/
Medio: ¡Ya no uses bloques if-else! Utilice la estrategia y el patrón de fábrica juntos