SOLID-Prinzipien in C#: Theorie und Praxis von A bis Z

Einleitung: Warum braucht man die SOLID-Prinzipien in C#?

Jeder C#-Entwickler stößt früher oder später auf das Problem von „schmutzigem Code“: Klassen, die alles Mögliche tun, unlesbare Abhängigkeiten und die Unmöglichkeit, Änderungen vorzunehmen, ohne das gesamte Projekt zu gefährden. SOLID ist ein Akronym für fünf fundamentale Prinzipien des objektorientierten Designs, formuliert von Robert C. Martin. Sie helfen dabei, flexiblen, wartbaren und testbaren Code in C# (.NET) zu erstellen.

In diesem Artikel werden wir jedes SOLID-Prinzip mit theoretischen Grundlagen und praktischen Beispielen in C# durchgehen. Sie erfahren, wie Sie sie in realen Projekten anwenden und typische Fehler vermeiden.

1. Single Responsibility Principle (SRP) – Prinzip der einzigen Verantwortung

Theorie

Eine Klasse sollte nur einen Grund für eine Änderung haben. Mit anderen Worten, jede Klasse ist nur für einen Teil der Funktionalität des Programms verantwortlich. Ein Verstoß gegen SRP führt dazu, dass eine Änderung einer Operation (z. B. Speichern in der Datenbank) die Berechnungs- oder Anzeigelogik beeinträchtigt.

Praxis in C#

Betrachten wir ein typisches Beispiel für einen SRP-Verstoß – eine Klasse, die gleichzeitig das Gehalt berechnet und den Mitarbeiter in der Datenbank speichert:

// ❌ SRP-Verstoß: Die Klasse macht zu vielpublic class Employee{    public string Name { get; set; }    public decimal Salary { get; set; }

    public decimal CalculateBonus()    {        return Salary * 0.1m;    }

    public void SaveToDatabase()    {        // Logik zum Speichern in der DB        Console.WriteLine("Mitarbeiter in der DB gespeichert");    }}

Beheben wir die Situation, indem wir die Verantwortlichkeiten trennen:

// ✅ SRP: Jede Klasse ist für ihre eigene Aufgabe verantwortlichpublic class Employee{    public string Name { get; set; }    public decimal Salary { get; set; }}

public class BonusCalculator{    public decimal Calculate(Employee employee)    {        return employee.Salary * 0.1m;    }}

public class EmployeeRepository{    public void Save(Employee employee)    {        Console.WriteLine("Mitarbeiter in der DB gespeichert");    }}

2. Open-Closed Principle (OCP) – Prinzip der Offenheit/Geschlossenheit

Theorie

Softwareentitäten (Klassen, Module, Funktionen) sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein. Das bedeutet, dass Sie neue Funktionalität hinzufügen können, ohne vorhandenen Code zu ändern.

Praxis in C#

Angenommen, wir müssen die Fläche verschiedener Formen berechnen. Ein OCP-Verstoß ist die Verwendung von if-else oder switch für jeden neuen Formtyp:

// ❌ OCP-Verstoß: Beim Hinzufügen einer neuen Form muss der Code geändert werdenpublic class AreaCalculator{    public double Calculate(object shape)    {        if (shape is Circle circle)            return Math.PI * circle.Radius * circle.Radius;        else if (shape is Rectangle rect)            return rect.Width * rect.Height;        // Beim Hinzufügen von Triangle müsste ein weiteres if ergänzt werden        return 0;    }}

Die Lösung – Abstraktion und Polymorphismus verwenden:

// ✅ OCP: Erweiterung durch Vererbung, ohne vorhandenen Code zu ändernpublic abstract class Shape{    public abstract double GetArea();}

public class Circle : Shape{    public double Radius { get; set; }    public override double GetArea() => Math.PI * Radius * Radius;}

public class Rectangle : Shape{    public double Width { get; set; }    public double Height { get; set; }    public override double GetArea() => Width * Height;}

public class AreaCalculator{    public double Calculate(Shape shape)    {        return shape.GetArea(); // Funktioniert für jede Form    }}

3. Liskov Substitution Principle (LSP) – Prinzip der Substitution von Barbara Liskov

Theorie

Objekte einer Basisklasse sollten durch Objekte ihrer Unterklassen ersetzt werden können, ohne dass die Korrektheit des Programms beeinträchtigt wird.