Strategy design pattern

Strategy design pattern

Strategy design pattern

Design pattern spielen eine wichtige Rolle in der Applikationsentwicklung, da sie die Kommunikation von Ideen und Architekturen vereinfachen.

Das strategy design pattern ist definitiv eines der Einfacheren. Es besagt, dass konkrete geteilte Verhalten in eigene Klassen externalisiert werden und und als Komponenten verwendet werden.

Das Tierbeispiel

Es ist ein ungeschriebenes Gesetz, dass es in jedem OOP Artikel ein Tierbeispiel geben muss - hier ist unser Beispiel:

Nehmen wir an, wir hätten mehrere verschiedene Tier-Klassen. Unsere Tiere besäßen eine Methode makeSound(), um ein Geräusch zu erzeugen (bellen, sprechen, …) und eine weitere Methode move(), um sich fortzubewegen (laufen, kriechen, …).

Der naive Ansatz

Wir bewegen uns in einer objektorientierten Entwicklungswelt - warum sollten wir nicht die Stärken der Objektorientierung nutzen? Warum definieren wir die Methoden nicht als abstrakt und überlassen die konkrete Implementierung den einzelnen Tieren?

 

abstract class Animal {
    abstract public void makeSound();
    abstract public void move();
}

Auf den ersten Blick sieht dieser Ansatz nach einer guten Idee aus. Bedenken wir jedoch die Codepflege, wird schell klar, dass es keine gute Idee ist: Das Verhalten “Bellen” z.B. müsste in vielen verschiedenen Tieren implementiert werden.

 

 

Allgemein ist davon abzuraten, dieselbe Logik an verschiedenen Stellen zu implementieren (don’t repeat yourself)

Wenn wir in diesem Fall einen Bug in einem der Verhalten fänden, so müssten wir diesen Bug in vielen verschiedenen Stellen beheben. Wenn wir ein feature hinzufügen wollten, so müssten wir dies an vielen verschiedenen Stellen implementieren. Der Aufwand jeder Aktion wäre um ein Vielfacher größer.

Was geschieht, wenn eine der Implementierungen beim Bug fixen vergessen wird? Was geschieht, wenn in einer der Implementierungen ein Fehler gemacht wird, weil dem Entwickler langweilig geworden ist?

Die Antwort auf beide Fragen ist die Folgende: Regressionsfehler und Unberechenbares verhalten.

Das strategy design pattern

Zurück zum Tierbeispiel: Wir nehmen nun Teile der Funktionalität und externalisieren diese in ihre eigenen Klassen. Wir haben nun eine Klasse für Bellen, eine für Sprechen, eine für Laufen, … .Jede dieser Klassen ist eine konkrete Implementierung eines spezifischen Verhalten.

Wir fügen auch zwei neue Interfaces hinzu, um diese Verhalten zusammenzuhalten: SoundInterface und MovementInterface.

 

abstract class Animal {
    protected SoundInterface sound;
    protected MovementInterfave movement;

    public void makeSound() {
        sound.makeSound();
    }

    public void move(){
        movement.move();
    }
}

Um diese Verhalten nun nutzen zu können, müssten die einzelnen Tierklassen lediglich die richtigen Verhalten in ihrem Konstruktor initialisieren. Mit dem strategy design pattern haben wir nun die spezifischen Verhalten isoliert und haben sichergestellt, dass sich hier kein doppelter Code ansammelt.

 

class Dog extends Animal {
    public Dog() {
    sound = SoundInterface.get('bark');
    movement = MovementInterface.get('4limb');
  }
}

But wait, there’s more

Eine der zusätzlichen features dieses design patterns ist, dass wir nun ein Verhalten zur Laufzeit auswechseln können: Tiere können sich nun Weiterentwickeln:

 

AbstractAnimal dog = AbstractAnimal.create("dog");
dog.makeSound(); // barks
dog.setSound(new SpeakingSound());
dog.makeSound(); // holy smokes, the dog just spokes

Über uns

land in sicht bietet digitale Lösungen für Destinationen und Leistungsträger im Tourismus: toubiz®-Infosystem für touristische Infrastruktur, Webportale und das Frontend für das TOMAS® Buchungssystem.

Standort Deutschland

Brühlmatten 16
79295 Sulzburg

Telefon +49 7634 56956-0

Standort Schweiz

Letzistrasse 29
9015 St. Gallen

Telefon ‭+41 71 571 069-0‬