Verwendung von Strategiemustern zur Vermeidung von Überkonditionierung

Vor einigen Wochen habe ich an Lösungen für den Globo Player gearbeitet, bei denen es notwendig war, bestimmte Verhaltensweisen in der Software während der Ausführung zu aktivieren und zu deaktivieren. Diese Art von Bedarf wird üblicherweise mit verketteten Bedingungen wie if-else und switch gelöst, aber dieser Ansatz ist nicht immer ideal.

In diesem Artikel stelle ich eine Lösung vor, die diese Herausforderung perfekt gemeistert hat und auf verschiedene Programmierszenarien angewendet werden kann.

Welche Strategie soll ich anwenden?

Stellen Sie sich vor, Sie sind gerade an einem unbekannten Ziel angekommen. Wenn Sie den Flughafen verlassen, haben Sie mehrere Möglichkeiten, zu Ihrem Hotel zu gelangen. Die günstigste Alternative ist das Mieten eines Fahrrads, allerdings würde dies mehr Zeit in Anspruch nehmen. Die Fahrt mit dem Bus wäre zwar etwas teurer, aber man kommt damit schneller und sicherer ans Ziel. Schließlich wäre die Anmietung eines Autos die schnellste Option, aber auch die teuerste.

Der wichtigste Punkt in dieser Situation ist zu verstehen, dass das Endziel unabhängig von der gewählten Strategie dasselbe ist: zum Hotel zu gelangen.

Diese Analogie kann auf die Softwareentwicklung angewendet werden. Wenn wir uns mit Szenarien befassen, in denen verschiedene Prozesse das gleiche Ziel erreichen wollen, können wir das Strategieentwurfsmuster als Hilfe nutzen.

Wenn Sie ohne Strategie programmieren ...

Stellen Sie sich vor, wir müssen ein Bankensystem entwickeln, das in der Lage ist, Gebühren basierend auf dem Kontotyp des Kunden zu berechnen, z. B. laufendes Konto, Sparkonto oder Prämie. Diese Berechnungen müssen zur Laufzeit durchgeführt werden, was eine Implementierung erfordert, die den Codefluss korrekt zur entsprechenden Berechnung leitet.

Im Prinzip wäre ein gängiger Ansatz, eine einfache Struktur verketteter Bedingungen zu verwenden, um das Problem schnell und funktional zu lösen:

class Banco {
  calcularTaxa(tipoConta, valor) {
    if (tipoConta === "corrente") {
      return valor * 0.02; // 2% de taxa
    } else if (tipoConta === "poupanca") {
      return valor * 0.01; // 1% de taxa
    } else if (tipoConta === "premium") {
      return valor * 0.005; // 0,5% de taxa
    } else {
      throw new Error("Tipo de conta não suportado.");
    }
  }
}

const banco = new Banco();
const taxa = banco.calcularTaxa("corrente", 1000); // Exemplo: R00
console.log(`A taxa para sua conta é: R$${taxa}`);

Während diese Lösung für einfache Szenarien gut funktioniert, was passiert, wenn die Bank in Zukunft fünf weitere Kontotypen hinzufügen muss?

calcularTaxa(tipoConta, valor) {
  if (tipoConta === "corrente") {
    return valor * 0.02; // 2% de taxa
  } else if (tipoConta === "poupanca") {
    return valor * 0.01; // 1% de taxa
  } else if (tipoConta === "premium") {
    return valor * 0.005; // 0,5% de taxa
  } else if (tipoConta === "estudante") {
    return valor * 0.001; // 0,1% de taxa
  } else if (tipoConta === "empresarial") {
    return valor * 0.03; // 3% de taxa
  } else if (tipoConta === "internacional") {
    return valor * 0.04 + 10; // 4% + taxa fixa de R
  } else if (tipoConta === "digital") {
    return valor * 0.008; // 0,8% de taxa
  } else if (tipoConta === "exclusiva") {
    return valor * 0.002; // 0,2% de taxa
  } else {
    throw new Error("Tipo de conta inválido!");
  }
}

Jetzt zeigt der Code ernsthafte Einschränkungen. Lassen Sie uns die Probleme dieses Ansatzes untersuchen:

1. Geringe Skalierbarkeit

Jedes Mal, wenn ein neuer Kontotyp hinzugefügt werden muss, muss die Methode „calcrateRate“ geändert werden. Dadurch erhöht sich kontinuierlich die Anzahl der Bedingungen, was den Code komplexer und schwieriger zu verwalten macht.

2. Hohe Abhängigkeit

Die Tarifberechnungslogik ist vollständig an die berechneRate-Methode gekoppelt. Änderungen an einem Kontotyp können sich unbeabsichtigt auf andere Kontotypen auswirken und das Risiko der Einführung von Fehlern erhöhen.

3. Codewiederholung

Ähnliche Snippets, z. B. Betrag * Gebühr, werden für jeden Kontotyp dupliziert. Dies reduziert die Wiederverwendung von Code und verstößt gegen das Prinzip DRY (Don't Repeat Yourself).

Im nächsten Schritt werden wir sehen, wie das Strategiemuster diese Probleme lösen und saubereren, skalierbaren und modularen Code fördern kann.

Eine Strategie nach der anderen!

Um die oben genannten Probleme zu vermeiden, behandeln wir jeden Kontotyp in der Software als isolierte Einheit. Dies liegt daran, dass jeder Kontotyp eine spezifische Gebührenberechnung hat und möglicherweise andere damit verbundene zukünftige Verhaltensweisen aufweist.

Anstatt eine Bank-Klasse mit einer berechneRate-Methode zu erstellen, die alle Operationen löst, erstellen wir eine Klasse für jeden Kontotyp:

class Banco {
  calcularTaxa(tipoConta, valor) {
    if (tipoConta === "corrente") {
      return valor * 0.02; // 2% de taxa
    } else if (tipoConta === "poupanca") {
      return valor * 0.01; // 1% de taxa
    } else if (tipoConta === "premium") {
      return valor * 0.005; // 0,5% de taxa
    } else {
      throw new Error("Tipo de conta não suportado.");
    }
  }
}

const banco = new Banco();
const taxa = banco.calcularTaxa("corrente", 1000); // Exemplo: R00
console.log(`A taxa para sua conta é: R$${taxa}`);

Dadurch wird sichergestellt, dass jeder Berechnungsvorgang innerhalb eines bestimmten Bereichs für Ihren Kontotyp gehalten wird. Jetzt haben wir isolierte Verhaltensweisen, die sich auf jeden Kontotyp konzentrieren:

Lösungsarchitektur basierend auf Strategien.

Aber wo befindet sich die gewünschte Kontoauswahl?

calcularTaxa(tipoConta, valor) {
  if (tipoConta === "corrente") {
    return valor * 0.02; // 2% de taxa
  } else if (tipoConta === "poupanca") {
    return valor * 0.01; // 1% de taxa
  } else if (tipoConta === "premium") {
    return valor * 0.005; // 0,5% de taxa
  } else if (tipoConta === "estudante") {
    return valor * 0.001; // 0,1% de taxa
  } else if (tipoConta === "empresarial") {
    return valor * 0.03; // 3% de taxa
  } else if (tipoConta === "internacional") {
    return valor * 0.04 + 10; // 4% + taxa fixa de R
  } else if (tipoConta === "digital") {
    return valor * 0.008; // 0,8% de taxa
  } else if (tipoConta === "exclusiva") {
    return valor * 0.002; // 0,2% de taxa
  } else {
    throw new Error("Tipo de conta inválido!");
  }
}

Beachten Sie, dass wir uns dafür entschieden haben, eine Kontostrategie im Konstruktor unserer Bank-Klasse zu übergeben, anstatt verkettete Entscheidungsstrukturen (if-else) zu erstellen. Dadurch kann die setConta-Methode zur Laufzeit beim Instanziieren der Bank den gewünschten Kontotyp auswählen. Die Tarifberechnung wird über this.conta.calcularTaxa(valor) durchgeführt.

class ContaCorrente {
  calcularTaxa(valor) {
    return valor * 0.02; // 2% de taxa
  }
}

class ContaPoupanca {
  calcularTaxa(valor) {
    return valor * 0.01; // 1% de taxa
  }
}

class ContaPremium {
  calcularTaxa(valor) {
    return valor * 0.005; // 0,5% de taxa
  }
}

Mit diesem Modell konnten wir das Strategiemuster auf einfache Weise anwenden und so eine flexiblere, skalierbarere Implementierung mit geringerer Kopplung gewährleisten.

Kann ich bei allem Strategie anwenden?

Das Strategiemuster ist eine leistungsstarke Lösung, wenn Sie das Verhalten einer Operation zur Laufzeit variieren müssen, ohne den Ausführungscode direkt an verschiedene Bedingungen oder Typen zu koppeln. Dieses Muster ist ideal für Szenarien, in denen das Verhalten einer Operation je nach Kontext variieren kann und in denen die Alternativen unabhängig voneinander sind.

Wann sollte das Strategiemuster verwendet werden?

• Abweichendes Verhalten: Wenn das Verhalten eines Systems abhängig von bestimmten Bedingungen dynamisch geändert werden muss (z. B. unterschiedliche Kontotypen im Bankbeispiel).
• Vermeiden Sie komplexe Bedingungen: Wenn die Entscheidungslogik auf vielen Flusskontrollstrukturen basiert, wie z. B. mehreren if-else oder switch, was die Wartung des Codes erschwert.
• Einfache Wartung und Erweiterung: Wenn Sie neue Verhaltensweisen hinzufügen möchten, ohne den vorhandenen Code zu ändern, erstellen Sie einfach neue Strategieklassen.
• Verhaltensentkopplung: Wenn Sie bestimmte Verhaltensweisen in verschiedenen Klassen isolieren möchten, um den Code modularer und flexibler zu gestalten.

Durch den Einsatz von Strategy garantieren wir, dass der Code sauberer, modularer und flexibler wird und fördern außerdem eine bessere Wartung und Erweiterung des Systems.

Das obige ist der detaillierte Inhalt vonVerwendung von Strategiemustern zur Vermeidung von Überkonditionierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!