Zum Inhalt
wannacode

Strategy

Kurz gesagt: Strategy legt jede Regel (etwa eine Zahlungsart) in ein eigenes Objekt hinter einem gemeinsamen Interface, damit du neue Regeln hinzufügst, ohne den Code anzufassen, der sie benutzt.

Problem

Der Checkout, der jede Zahlungsart kennt

Der Onlineshop nimmt fünf Zahlungsarten an. Nachnahme kostet 2,50 € mehr, ein Gutschein nimmt 10 € ab, bei einer Überweisung gibt es 2 % Rabatt, und Ratenzahlung kostet 5 % mehr. Der Checkout berechnet den Betrag so:

static decimal Total(string method, decimal amount)
{
    if (method == "Karte")
    {
        return amount;
    }
    else if (method == "Nachnahme")
    {
        return amount + 2.50m;
    }
    else if (method == "Gutschein")
    {
        return Math.Max(amount - 10, 0);
    }
    else if (method == "Überweisung")
    {
        return amount * 0.98m;
    }
    else if (method == "Ratenzahlung")
    {
        return amount * 1.05m;
    }
    throw new ArgumentException("Unbekannte Zahlungsart: " + method);
}
Console.WriteLine($"Karte: {Total("Karte", 80):F2} €");
Console.WriteLine($"Nachnahme: {Total("Nachnahme", 80):F2} €");
Console.WriteLine($"Gutschein: {Total("Gutschein", 80):F2} €");
Console.WriteLine($"Überweisung: {Total("Überweisung", 80):F2} €");
Console.WriteLine($"Ratenzahlung: {Total("Ratenzahlung", 80):F2} €");
Ausgabe
Karte: 80.00 €
Nachnahme: 82.50 €
Gutschein: 70.00 €
Überweisung: 78.40 €
Ratenzahlung: 84.00 €

Es funktioniert. Aber jeden Monat kommt eine neue Art, und jede ist ein neuer Zweig in dieser Methode. Dieselbe Kette steckt auch in der Rechnung und in der Bestätigungs-E-Mail. Jemand fügt Apple Pay an zwei der drei Stellen hinzu, und der Kunde bekommt eine E-Mail mit „Unbekannte Zahlungsart“.

Gutscheine gelten nicht mehr nur für 10 €. Um den Wert hineinzureichen, bekommt die Methode einen dritten Parameter, und jede Stelle, die sie aufruft, ändert sich, sogar bei Kartenzahlungen, wo es keinen Gutschein gibt. Der Code, durch den jede Zahlung geht, wird bei jeder Änderung angefasst.

Die Idee

Strategy: die Regel für sich, der Checkout fragt

Was sich ändert, ist eins: wie der Betrag berechnet wird. Was sich nicht ändert, ist der Checkout: Er nimmt den Betrag, fragt und rundet.

Also wandert die Regel in ein eigenes Objekt. Alle Arten haben eine gemeinsame Form: ein Interface mit einer Methode, die einen Betrag nimmt und zurückgibt, wie viel zu zahlen ist. Der Checkout hält einen Verweis auf ein solches Objekt und ruft die Methode auf, ohne zu wissen, welches Objekt es ist.

Das ist das Strategy-Muster. Es hat drei Rollen:

  • der Checkout hält die Strategy und ruft sie auf. In Büchern heißt er der Kontext;
  • die gemeinsame Form: das Interface PaymentMethod (IPaymentMethod in C#);
  • die konkreten Strategies: eine Klasse für jede Art.

Eine neue Art ist eine neue Strategy. Der Checkout wird nicht angefasst.

Sieh es dir an

Der Checkout und drei Zahlungsarten

Die gemeinsame Form:

interface IPaymentMethod
{
    decimal Total(decimal amount);
}
Drei Arten, jede in einer eigenen Klasse. Der Gutschein hat ein Feld mit seinem Wert, also kommt der Wert in den Konstruktor, statt ein Parameter für alle zu sein:
class Card : IPaymentMethod
{
    public decimal Total(decimal amount)
    {
        return amount;
    }
}


class CashOnDelivery : IPaymentMethod
{
    public decimal Total(decimal amount)
    {
        return amount + 2.50m;
    }
}


class Voucher : IPaymentMethod
{
    private decimal value;


    public Voucher(decimal value)
    {
        this.value = value;
    }


    public decimal Total(decimal amount)
    {
        return Math.Max(amount - value, 0);
    }
}
Der Checkout hält die Strategy in der Property Method und rechnet damit. Eine Zuweisung an Method wechselt sie:
class Checkout
{
    public IPaymentMethod Method { get; set; }


    public Checkout(IPaymentMethod method)
    {
        Method = method;
    }


    public decimal Total(decimal amount)
    {
        return Math.Round(Method.Total(amount), 2);
    }
}
var checkout = new Checkout(new Card());
Console.WriteLine($"Karte: {checkout.Total(80):F2} €");


checkout.Method = new CashOnDelivery();
Console.WriteLine($"Nachnahme: {checkout.Total(80):F2} €");


checkout.Method = new Voucher(10);
Console.WriteLine($"Gutschein: {checkout.Total(80):F2} €");
Ausgabe
Karte: 80.00 €
Nachnahme: 82.50 €
Gutschein: 70.00 €

var checkout = new Checkout(new Card());
Console.WriteLine($"Karte: {checkout.Total(80):F2} €");


checkout.Method = new CashOnDelivery();
Console.WriteLine($"Nachnahme: {checkout.Total(80):F2} €");


checkout.Method = new Voucher(10);
Console.WriteLine($"Gutschein: {checkout.Total(80):F2} €");
Schritt für Schritt, in Worten
  1. Der Checkout bekommt eine Karte: sein Feld Method zeigt auf das Objekt Card.
  2. total(80): Der Checkout kennt die Zahlungsart nicht. Er fragt die Strategy nur nach dem Betrag und bekommt 80.00 zurück.
  3. Eine neue Art. Die Property Method stellt das Feld auf das Objekt CashOnDelivery um. In Checkout ändert sich keine einzige Zeile.
  4. Dasselbe total(80), eine andere Antwort: 82.50.
  5. Ein Gutschein über 10: ein Objekt mit einem eigenen Feld value. Auf die alten Strategies zeigt nichts mehr.
  6. Der Gutschein nimmt 10 ab: 70.00. Drei Zahlungsarten, und der Checkout ist die ganze Zeit dasselbe Objekt mit demselben Code.

Der Checkout ist ein Objekt mit einem Stück Code für das ganze Programm. Nur das, worauf das Feld zeigt, ändert sich.

Sieh es dir an

Eine neue Art, ohne den Checkout anzufassen

Überweisung und Ratenzahlung kommen als zwei neue Klassen:

class BankTransfer : IPaymentMethod
{
    public decimal Total(decimal amount)
    {
        return amount * 0.98m;
    }
}


class Installments : IPaymentMethod
{
    public decimal Total(decimal amount)
    {
        return amount * 1.05m;
    }
}
var checkout = new Checkout(new BankTransfer());
Console.WriteLine($"Überweisung: {checkout.Total(80):F2} €");


checkout.Method = new Installments();
Console.WriteLine($"Ratenzahlung: {checkout.Total(80):F2} €");
Ausgabe
Überweisung: 78.40 €
Ratenzahlung: 84.00 €

Keine einzige Zeile des Checkouts hat sich geändert. Du kannst die Kartenzahlung nicht kaputt machen, während du Überweisungen hinzufügst, weil der Code der Karte nicht vor dir liegt.

Es gibt noch etwas. Wenn die neue Klasse die Methode vergisst oder ihren Namen falsch schreibt, lässt sich das Programm nicht kompilieren:

class Installments : IPaymentMethod
{
    public decimal Totl(decimal amount)
    {
        return amount * 1.05m;
    }
}
Fehler
error CS0535: 'Installments' does not implement interface member 'IPaymentMethod.Total(decimal)'

Bei der Kette von ifs zeigt sich ein falsch geschriebener Methodenname erst, wenn ein Kunde diese Art wählt.

Sieh es dir an

Welche Art der Kunde wählt

Der Kunde tippt die Art als Text. Die Kette von ifs, die die Regel gewählt hat, wird zu einer Tabelle: Name → Strategy.

var methods = new Dictionary<string, IPaymentMethod>
{
    ["Karte"] = new Card(),
    ["Nachnahme"] = new CashOnDelivery(),
    ["Gutschein"] = new Voucher(10),
};


string choice = Console.ReadLine();
if (methods.TryGetValue(choice, out IPaymentMethod method))
{
    var checkout = new Checkout(method);
    Console.WriteLine($"{choice}: {checkout.Total(80):F2} €");
}
else
{
    Console.WriteLine("Keine solche Zahlungsart: " + choice);
}
Eingabe
Nachnahme
Ausgabe
Nachnahme: 82.50 €

Eine unbekannte Art erreicht den Checkout nie:

Eingabe
PayPal
Ausgabe
Keine solche Zahlungsart: PayPal

Die Wahl steht weiterhin an einer Stelle, aber jetzt sind es Daten. Eine neue Art ist eine neue Zeile in der Tabelle und eine neue Klasse.

Genauer, für Neugierige

Ein Lambda lässt sich nicht dort übergeben, wo ein Interface erwartet wird: C# meldet den Fehler CS1660 (siehe die Lektion „Entwurfsmuster“ im Modul „Modernes C#“). Wenn die Strategy eine einzelne Funktion ist, hat C# den Delegate Func<decimal, decimal>, und der Checkout kann den statt eines Interfaces halten. Das Interface lohnt sich, wenn die Strategy ein eigenes Feld (den Gutschein), einen Namen oder mehr als eine Methode hat.

Probier es aus

Sag die Ausgabe voraus

Die Bestellung kostet 8 €, und der Gutschein 10 €. Dann wechselt der Checkout zu Nachnahme. Was gibt das Programm aus?

var checkout = new Checkout(new Voucher(10));
Console.WriteLine($"{checkout.Total(8):F2} €");


checkout.Method = new CashOnDelivery();
Console.WriteLine($"{checkout.Total(8):F2} €");
Antwort

Probier es aus

Finde den Fehler

Ein Gutschein soll einmal eingelöst werden. Jemand „verbraucht“ ihn mitten in der Strategy:

class Voucher : IPaymentMethod
{
    private decimal value;


    public Voucher(decimal value)
    {
        this.value = value;
    }


    public decimal Total(decimal amount)
    {
        decimal result = Math.Max(amount - value, 0);
        value = 0;
        return result;
    }
}
var checkout = new Checkout(new Voucher(10));
Console.WriteLine($"Bestellvorschau: {checkout.Total(80):F2} €");
Console.WriteLine($"Zahlung: {checkout.Total(80):F2} €");
Ausgabe
Bestellvorschau: 70.00 €
Zahlung: 80.00 €

Die Vorschau zeigte 70 €, und die Zahlung verlangte 80 €. In welcher Zeile steckt der Fehler?

Wähle die Zeile mit dem Fehler.

Die Idee

Wann du es nicht brauchst

Strategy hat seinen Preis: ein Interface und eine Klasse für jede Variante statt eines if. Es lohnt sich nicht, wenn:

  • es zwei Varianten gibt und sie sich nicht ändern. „Mit Mehrwertsteuer oder ohne“ ist ein if;
  • die Regel an einer Stelle benutzt wird und niemand sie anfasst;
  • es nur eine Strategy gibt, „auf Verdacht“. Ein Interface mit einer Implementierung ist Code, den du lesen musst, ohne etwas dafür zu bekommen.

Es lohnt sich, wenn die Varianten wachsen, sich ändern, während das Programm läuft (der Kunde wählt), oder wenn verschiedene Teile des Programms verschiedene Regeln brauchen.

Übung

Apple Pay, ohne den Checkout anzufassen

Löse die Aufgabe in deinem Editor.

Apple Pay. Der Shop bekommt Apple Pay mit 1 % Gebühr auf den Betrag. Füge eine Klasse ApplePay hinzu und bezahle damit eine Bestellung über 80 €. Der Checkout und die anderen Arten werden nicht angefasst.

Ausgabe
Apple Pay: 80.80 €

Weitere Aufgaben

  • Nachnahme kostenlos über 100 €. Schreibe eine Nachnahme-Strategy, die bei Bestellungen über 100 € keine 2,50 € berechnet. Führe sie mit 80 € und mit 120 € aus.
  • Die Art aus der Eingabe. Füge Überweisung und Ratenzahlung zur Tabelle von der Karte „Welche Art der Kunde wählt“ hinzu. Lies auch den Betrag aus der Eingabe.
  • Eine Geschenkkarte mit Guthaben. Die Karte hat ein Guthaben von 50 €: Sie zahlt, was sie kann, und den Rest zahlt die Bankkarte. Überlege, wo das neue Guthaben festgehalten wird. Ändert es die Strategy oder die Bestellung nach der Zahlung?

Test

Teste dich

1. Der Shop bekommt Apple Pay. Was schreibst du mit Strategy?
2. Was hält der Checkout bei Strategy?
3. Die Gutschein-Strategy setzt ihren Wert bei jedem Aufruf von total auf null. Der Checkout fragt einmal für die Vorschau und einmal für die Zahlung. Was passiert?
4. Wann brauchst du Strategy nicht?

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·