Strategy Pattern in C#: Flexibler & wartbarer Code

Strategy Pattern: Flexibles Verhalten durch austauschbare Algorithmen

‍

In der Softwareentwicklung stehen Teams oft vor der Herausforderung, flexibel auf wechselnde Anforderungen zu reagieren. Ein Algorithmus, der heute passt, kann morgen schon unzureichend sein – sei es bei Sortierverfahren, Authentifizierungsmethoden oder Preisberechnungen. Wird das Verhalten jedoch fest im Code verankert, führt jede Anpassung schnell zu unnötigem Aufwand, unübersichtlicher Logik und schwer wartbaren Systemen.

An dieser Stelle setzt das Strategy Pattern an. Es bietet eine elegante Möglichkeit, verschiedene Verhaltensweisen sauber voneinander zu trennen und zur Laufzeit auszutauschen. Der Artikel zeigt, wie das Strategy Pattern in C# funktioniert, wie Flexibler & wartbarer Code gebildet wid und wie Entwickler es praxisnah einsetzen können.

‍

Problembeschreibung

In vielen Anwendungen gibt es Situationen, in denen eine bestimmte Funktionalität in verschiedenen Varianten existiert. Ein typisches Beispiel ist die Berechnung von Rabatten: Je nach Kundengruppe oder Aktion soll ein anderer Algorithmus angewendet werden.
Wenn diese Varianten direkt im Code über if- oder switch-Anweisungen implementiert werden, entstehen schnell lange und schwer wartbare Blöcke. Änderungen oder Erweiterungen erfordern Eingriffe an mehreren Stellen, was die Fehleranfälligkeit erhöht und den Code unübersichtlich macht.

‍

Hintergrund und Analyse

Das Strategy Pattern wurde entwickelt, um genau dieses Problem zu lösen. Es trennt die Definition eines Algorithmus von seiner Verwendung. Das bedeutet:

• Ein Verhalten (z. B. Rabattberechnung) wird durch eine gemeinsame Schnittstelle abstrahiert.

• Konkrete Implementierungen enthalten die verschiedenen Varianten des Algorithmus.

• Der aufrufende Code („Context“) kennt nur die Schnittstelle und kann zur Laufzeit eine konkrete Strategie auswählen oder austauschen.

‍

Diese Entkopplung reduziert Abhängigkeiten, erhöht die Wiederverwendbarkeit und erleichtert das Testen, da jede Strategie isoliert geprüft werden kann.

‍

Lösungsansatz – Strategy Pattern in Aktion

Beispiel: Rabattberechnung in einem Onlineshop in C#

‍

1// Die gemeinsame Strategy-Schnittstelle 
2
3public interface IDiscountStrategy 
4{ 
5    double ApplyDiscount(double price); 
6}

‍

1// Konkrete Strategies 
2
3public class NoDiscount : IDiscountStrategy 
4{ 
5    public double ApplyDiscount(double price) => price; 
6} 
7public class PercentageDiscount : IDiscountStrategy 
8{ 
9    private readonly double _percent; 
10    public PercentageDiscount(double percent) => _percent = percent; 
11    public double ApplyDiscount(double price) => price * (1 - _percent / 100); 
12}

‍

1// Kontext 
2
3public class ShoppingCart 
4{
5    private IDiscountStrategy _discountStrategy; 
6    public ShoppingCart(IDiscountStrategy discountStrategy)  
7        => _discountStrategy = discountStrategy; 
8    public void SetDiscountStrategy(IDiscountStrategy strategy)  
9        => _discountStrategy = strategy; 
10    public double Checkout(double totalPrice)  
11        => _discountStrategy.ApplyDiscount(totalPrice); 
12} 

‍

1// Beispielnutzung 
2
3class Program 
4
5{ 
6    static void Main() 
7    
8    { 
9        var cart = new ShoppingCart(new NoDiscount()); 
10        Console.WriteLine($"Ohne Rabatt: {cart.Checkout(100)}"); 
11        cart.SetDiscountStrategy(new PercentageDiscount(20)); 
12        Console.WriteLine($"Mit 20% Rabatt: {cart.Checkout(100)}"); 
13    } 
14} 

‍

Mit dieser Struktur bleibt die Rabattlogik flexibel: neue Strategien können jederzeit ergänzt werden, ohne dass bestehender Code angepasst werden muss. Statt verschachtelter if-Abfragen entscheidet der Kontext (hier: ShoppingCart), welche Strategie gerade aktiv ist.

‍‍

Fazit

Das Strategy Pattern bietet eine saubere Lösung für Situationen, in denen verschiedene Varianten einer Logik benötigt werden. Durch die Trennung von Algorithmus und Kontext lassen sich Verhaltensweisen flexibel austauschen, leicht erweitern und unabhängig testen. So bleibt der Code übersichtlich und anpassbar, auch wenn neue Anforderungen hinzukommen.

Gerade in wachsenden Projekten zahlt sich dieses Muster aus, weil es langfristig für Struktur und Wartbarkeit sorgt. Statt endloser if-else-Ketten können Entwickler klare Strategien definieren und gezielt einsetzen – ein kleiner Architekturwechsel mit großem Effekt.