Clean Code und SOLID-Prinzipien

Dieser Beitrag ist eine Begriffserklärung zu Clean Code & SOLID – inklusive Prüfungsfragen, Kernelementen und Tags.

In a Nutshell

Clean Code steht für lesbaren, wartbaren, fehlerarmen Code. SOLID sind fünf zentrale Leitlinien für objektorientiertes Design.

Kompakte Fachbeschreibung

Clean Code fokussiert u.a. Namensgebung, Struktur, Wiederverwendbarkeit und kleine, verständliche Funktionen.

SOLID:

• S (SRP): Eine Klasse hat genau eine Verantwortlichkeit.
• O (OCP): Offen für Erweiterung, geschlossen für Änderung.
• L (LSP): Subtypen müssen Basistypen sauber ersetzen können.
• I (ISP): Viele kleine Interfaces statt weniger großer.
• D (DIP): Abhängigkeiten über Abstraktionen, nicht konkrete Klassen.

Prüfungsrelevante Stichpunkte

• Clean Code = lesbar, wartbar
• SRP: eine Klasse = eine Aufgabe
• OCP: erweiterbar ohne Änderung
• LSP: Subklassen korrekt substituierbar (IHK-relevant)
• ISP: Interfaces trennen (Praxis)
• DIP: Abhängigkeit über Interfaces
• Wirtschaftlichkeit: weniger Bugs, leichteres Onboarding
• Doku: Prinzipien in Architekturbeschreibung erwähnen

Kernkomponenten

1. Sprechende Namen
2. Kapselung/SRP
3. Vererbung nach LSP
4. Vermeidung von God Objects
5. ISP-Interfaces
6. Abstraktion/DIP
7. Unit Tests
8. Refactoring
9. Diagramme zur Erklärung
10. Codeanalyse-Tools (SonarQube)

Praxisbeispiel (SRP)

class ReportPrinter {
  public void print(PDFReport report) {
    // nur drucken, keine Report-Erstellung
  }
}

Vorteile und Nachteile

Vorteile

• Verständlicher Code
• Bessere Testbarkeit
• Weniger Kopplung
• Strukturierte Architektur

Nachteile

• Höherer Initialaufwand
• Übertriebene Anwendung kann fragmentieren

Typische Prüfungsfragen (mit Kurzantwort)

1. Was bedeutet Clean Code? Lesbarer, wartbarer Code.
2. Welche SOLID-Prinzipien gibt es? SRP, OCP, LSP, ISP, DIP.
3. Was ist ein God Object? Klasse mit zu vielen Verantwortlichkeiten.
4. Warum ist DIP wichtig? Entkoppelt High-Level von Low-Level.

Freie Antwort

SOLID sind Leitlinien, keine starren Regeln. In Prüfungen zählt, ein Prinzip erklären und anhand eines Beispiels begründen zu können – ohne Overengineering.

Lernstrategie

1. Kleine Clean-Code-Kapitel lesen.
2. Eigenen Code refactoren (SRP/LSP).
3. Pro Prinzip ein Beispiel formulieren.
4. Zu große Klassen vermeiden.

Themenanalyse

• Kern: OOP, Designprinzipien
• Herausforderungen: Overengineering
• Sicherheit: weniger versteckte Zustände
• Doku: Architekturentscheidungen
• Wirtschaftlichkeit: geringere Bugrate

Weiterführende Infos

1. https://refactoring.guru/design-patterns/principles
2. https://www.sonarsource.com/products/sonarqube/