Au fur et à mesure que nous avançons dans un projet, perdus dans des blocs if-else, aux prises avec des conditions complexes et un code répétitif, nous recherchons une solution. Mais pourquoi devrions-nous rester coincés dans des blocs if-else ? Dans cet article, découvrons comment éliminer la confusion if-else avec les modèles de stratégie et d'usine.

Problème : confusion « si-sinon »

Disons que vous développez une application de commerce électronique et que vous devez prendre en charge différentes méthodes de paiement telles que la carte de crédit, la carte de débit et la crypto-monnaie. Vous commencez avec des blocs if-else pour traiter les paiements :

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");
        }
    }
}

Bien que cela puisse paraître simple au premier abord, à mesure que les méthodes de paiement augmentent, la complexité if-else augmentera également. Un nouveau mode de paiement signifie ajouter une nouvelle condition. Le résultat est une pile de code difficile à gérer. Et cette méthode est contraire au principe ouvert-fermé.

Mais nous pouvons utiliser à la fois les modèles Strategy et Factory pour résoudre ce problème.

Tout d'abord, créons une énumération :

public enum PaymentType {
    CREDIT_CARD,
    DEBIT_CARD,
    CRYPTO
}

Solution : nettoyage avec un modèle de stratégie

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())));
    }
}

A ce stade, une stratégie distincte pour chaque moyen de paiement est mise en œuvre à partir d'une interface commune. Maintenant, avec Factory Pattern, nous allons décider quelle stratégie choisir.

Étape 2 : Choisir une stratégie avec un modèle d'usine

Dans cette étape, nous pouvons rendre le Factory Pattern plus propre et optimisé avec 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;
    }
}

Dernière étape : réorganisation des classes de service

Maintenant, utilisons ce que nous avons fait.

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);
    }
}

Dans l’état actuel des choses, nous n’avons pas besoin de blocs if-else pour le traitement des paiements. Grâce à Strategy et Factory Patterns, notre code est plus propre, modulaire et extensible.

Pourquoi devrions-nous utiliser ces modèles ?

1. Extensibilité : L'ajout d'un nouveau moyen de paiement ne nécessite qu'une nouvelle classe et quelques lignes de code.
2. Lisibilité : En utilisant des stratégies et des usines au lieu de blocs if-else, vous rendez votre code plus compréhensible et gérable.
3. Maintenabilité : Grâce à la stratégie et au modèle d'usine, des modifications du code peuvent être apportées sans affecter les autres éléments de code.

Conclusion : de la confusion à la clarté

Si vous travaillez sur un projet en pleine croissance, vous ne devez pas utiliser de blocs if-else. Les modèles de stratégie et d'usine sont des solutions parfaites pour rendre votre code plus propre, modulaire et maintenable.

Comme vous pouvez le voir dans cet article, l'utilisation de modèles de conception au lieu de blocs if-else pour gérer les transactions de paiement rend le projet plus développable et améliore la lisibilité du code. Essayez ces modèles dans votre prochain projet au lieu d'utiliser des blocs if-else.

...

Merci d'avoir lu mon article ! Si vous avez des questions, des commentaires ou des réflexions que vous aimeriez partager, j'aimerais les entendre dans les commentaires.

Vous pouvez me suivre sur dev.to pour plus d'informations sur ce sujet et mes autres articles.

Merci??

Pour me suivre sur LinkedIn : https://www.linkedin.com/in/tamerardal/
Medium : N'utilisez plus de blocs if-else ! Utiliser la stratégie et le modèle d'usine ensemble