Während wir in einem Projekt voranschreiten, uns in if-else-Blöcken verlieren, mit komplexen Bedingungen und sich wiederholendem Code kämpfen, suchen wir nach einer Lösung. Aber warum sollten wir in Wenn-Sonst-Blöcken stecken bleiben? In diesem Artikel erfahren Sie, wie Sie die Wenn-Sonst-Verwirrung mithilfe von Strategie- und Fabrikmustern beseitigen können.

Problem: Wenn-sonst-Verwirrung

Angenommen, Sie entwickeln eine E-Commerce-Anwendung und müssen verschiedene Zahlungsmethoden wie Kreditkarte, Debitkarte und Kryptowährung unterstützen. Sie beginnen mit if-else-Blöcken, um Zahlungen zu verarbeiten:

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

Obwohl es auf den ersten Blick einfach erscheinen mag, wird mit zunehmenden Zahlungsmethoden auch die Komplexität der If-Else-Funktionen zunehmen. Eine neue Zahlungsart bedeutet das Hinzufügen einer neuen Bedingung. Das Ergebnis ist ein Haufen Code, der schwer zu verwalten ist. Und diese Methode widerspricht dem Open-Closed-Prinzip.

Aber wir können sowohl das Strategie- als auch das Fabrikmuster verwenden, um dieses Problem zu lösen.

Erstellen wir zunächst eine Enumeration:

public enum PaymentType {
    CREDIT_CARD,
    DEBIT_CARD,
    CRYPTO
}

Lösung: Bereinigen mit Strategiemuster

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

In dieser Phase wird über eine gemeinsame Schnittstelle eine separate Strategie für jede Zahlungsmethode implementiert. Jetzt entscheiden wir mit Factory Pattern, welche Strategie wir wählen.

Schritt 2: Strategie mit Factory-Muster auswählen

In diesem Schritt können wir das Factory Pattern mit EnumMap sauberer und optimiert machen.

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

Letzter Schritt: Reorganisation der Serviceklasse

Nun nutzen wir, was wir getan haben.

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

So wie es ist, benötigen wir für die Zahlungsabwicklung keine if-else-Blöcke. Dank Strategy und Factory Patterns ist unser Code sauberer, modular und erweiterbar.

Warum sollten wir dieses Muster verwenden?

1. Erweiterbarkeit: Das Hinzufügen einer neuen Zahlungsmethode erfordert nur eine neue Klasse und ein paar Zeilen Code.
2. Lesbarkeit: Durch die Verwendung von Strategien und Factory anstelle von if-else-Blöcken machen Sie Ihren Code verständlicher und verwaltbarer.
3. Wartbarkeit: Mit der Strategie und dem Factory-Muster können Änderungen am Code vorgenommen werden, ohne dass sich dies auf andere Codeteile auswirkt.

Fazit: Von der Verwirrung zur Klarheit

Wenn Sie an einem wachsenden Projekt arbeiten, sollten Sie keine if-else-Blöcke verwenden. Strategie- und Factory-Muster sind perfekte Lösungen, um Ihren Code sauberer, modularer und wartbarer zu machen.

Wie Sie in diesem Artikel sehen können, macht die Verwendung von Entwurfsmustern anstelle von if-else-Blöcken zur Verwaltung von Zahlungstransaktionen das Projekt entwicklungsfähiger und verbessert die Lesbarkeit des Codes. Probieren Sie diese Muster in Ihrem nächsten Projekt aus, anstatt if-else-Blöcke zu verwenden.

...

Danke, dass Sie meinen Artikel gelesen haben! Wenn Sie Fragen, Feedback oder Gedanken haben, die Sie teilen möchten, würde ich mich freuen, diese in den Kommentaren zu hören.

Sie können mir auf dev.to folgen, um weitere Informationen zu diesem Thema und meinen anderen Beiträgen zu erhalten.

Danke schön??

Um mir auf LinkedIn zu folgen: https://www.linkedin.com/in/tamerardal/
Mittel: Verwenden Sie keine if-else-Blöcke mehr! Strategie und Fabrikmuster gemeinsam nutzen