SOLID-Prinzipien in Java: Vollständiger Leitfaden von der Theorie zum Code

SOLID-Prinzipien in Java: Von der Theorie zur Praxis

SOLID ist ein Akronym für fünf fundamentale Prinzipien der objektorientierten Programmierung, formuliert von Robert C. Martin (Uncle Bob). Diese Prinzipien helfen Entwicklern, flexiblen, wartbaren und leicht erweiterbaren Code zu erstellen. In diesem Artikel analysieren wir jedes SOLID-Prinzip anhand von Java-Beispielen, von der einfachen Theorie bis zur realen Praxis.

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

Theorie: Eine Klasse sollte nur einen Grund für Änderungen haben. Mit anderen Worten: Jede Klasse sollte für genau eine Funktionalität verantwortlich sein.

Verletzung des SRP:

public class Employee {    public void calculatePay() { /* Gehaltsberechnung */ }    public void saveToDatabase() { /* Speichern in der DB */ }    public void generateReport() { /* Berichtserstellung */ }}

Korrektur:

public class Employee { /* nur Daten */ }

public class PayCalculator {    public void calculatePay(Employee emp) { /* ... */ }}

public class EmployeeRepository {    public void save(Employee emp) { /* ... */ }}

public class ReportGenerator {    public void generate(Employee emp) { /* ... */ }}

Jetzt hat jede Klasse eine klare, einzige Verantwortung, was das Testen und die Wartung vereinfacht.

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.

Verletzung des OCP:

public class ShapeDrawer {    public void draw(String shapeType) {        if ("circle".equals(shapeType)) {            // Kreis zeichnen        } else if ("rectangle".equals(shapeType)) {            // Rechteck zeichnen        }    }}

Korrektur mittels Polymorphismus:

public interface Shape {    void draw();}

public class Circle implements Shape {    @Override    public void draw() { /* Kreis zeichnen */ }}

public class Rectangle implements Shape {    @Override    public void draw() { /* Rechteck zeichnen */ }}

public class ShapeDrawer {    public void draw(Shape shape) {        shape.draw();    }}

Um eine neue Form (z. B. Triangle) hinzuzufügen, muss der vorhandene Code nicht geändert werden – es wird einfach eine neue Klasse erstellt, die das Interface Shape implementiert.

3. Liskov Substitution Principle (LSP) — Prinzip der Substitution nach Barbara Liskov

Theorie: Objekte in einem Programm sollten durch Instanzen ihrer Subtypen ersetzbar sein, ohne die Korrektheit des Programms zu beeinträchtigen. Wenn S ein Subtyp von T ist, können Objekte vom Typ T durch Objekte vom Typ S ersetzt werden, ohne dass die Funktionalität gestört wird.

Klassische Verletzung des LSP:

public class Rectangle {    protected int width, height;    public void setWidth(int w) { width = w; }    public void setHeight(int h) { height = h; }    public int getArea() { return width * height; }}

public class Square extends Rectangle {    @Override    public void setWidth(int w) {        super.setWidth(w);        super.setHeight(w);    }    @Override    public void setHeight(int h) {        super.setWidth(h);        super.setHeight(h);    }}

Ein Client, der mit Rectangle arbeitet, erwartet, dass eine Änderung der Breite die Höhe nicht beeinflusst. Das Quadrat verletzt diese Erwartung. Lösung: Verwendung eines gemeinsamen Interfaces oder separater Klassen ohne Vererbung.

4. Interface Segregation Principle (ISP) — Prinzip der Schnittstellentrennung

Theorie: Clients sollten nicht von Methoden abhängig sein, die sie nicht verwenden. Es ist besser, mehrere spezialisierte Interfaces zu haben als ein einziges "fettes".

Verletzung des ISP: