SOLID: Prinzipien, 5 OOP-Regeln und Anwendung in der Entwicklung

Was ist SOLID? Übersicht über die fünf Prinzipien

SOLID — ein mnemonisches Akronym, das fünf Prinzipien des objektorientierten Designs darstellt. Der Begriff wurde von Robert C. Martin im Artikel „Design Principles and Design Patterns“ (2000) eingeführt und später im Buch „Agile Software Development: Principles, Patterns, and Practices“ (2002) popularisiert. SOLID ist kein Framework oder eine Bibliothek — es ist eine Sammlung von Praktiken, die Code weniger gekoppelt, testbarer und leichter änderbar machen.

Laut Clean Coder Blog, 2014, löst jedes SOLID-Prinzip ein bestimmtes Design-Problem: SRP bekämpft God-Klassen, OCP verhindert kaskadierende Änderungen, LSP schützt vor falscher Vererbung, ISP vermeidet große Schnittstellen und DIP reduziert starke Kopplung. Zusammen bilden sie die Grundlage von Clean Architecture, die in Android-Projekten mit MVP, MVVM und MVI verwendet wird.

SRP: Single Responsibility Principle

Single Responsibility Principle (SRP) — Prinzip der einzigen Verantwortung. Die Formulierung: „Eine Klasse sollte nur einen Grund zur Änderung haben.“ Das bedeutet, dass jedes Modul oder jede Klasse für genau eine Funktionalität oder eine Domänenentität verantwortlich ist. Wenn eine Klasse sowohl Benutzer als auch E-Mail-Versand verwaltet — hat sie zwei Änderungsgründe, was SRP verletzt.

Laut Robert C. Martin, 2002, ist SRP das wichtigste und gleichzeitig am häufigsten verletzte Prinzip. In der mobilen Entwicklung wird SRP oft in Activity/Fragment verletzt, indem UI-Logik, Navigation, Netzwerk und Geschäftslogik kombiniert werden. Die Lösung besteht darin, jede Schicht in eine separate Klasse zu extrahieren: ViewModel für UI-Logik, Repository für Daten, NavController für Navigation.

SRP-Beispiel: Zerlegung von UserManager

Betrachten Sie die Klasse UserManager, die ein Profil lädt, Einstellungen speichert und E-Mails sendet. Dies sind drei unterschiedliche Verantwortlichkeiten, die jeweils in eine separate Klasse extrahiert werden sollten: UserProfileRepository (Laden), UserSettingsStorage (Speichern) und EmailService (Senden). Der Client-Code (ViewModel) verwendet alle drei durch Dependency Injection, und jede Klasse wird isoliert einfach getestet und kann geändert werden, ohne andere zu beeinflussen.

// ❌ SRP-Verletzung: Activity kennt Netzwerk, DB und UI
class ProfileActivity : AppCompatActivity() {
    fun loadProfile() {
        api.getUser() // Netzwerkaufruf
        db.saveUser()    // DB-Operation
        updateUI()         // UI-Aktualisierung
    }
}

// ✅ SRP eingehalten: Schichten sind getrennt
class ProfileViewModel : ViewModel() {
    private val repo = UserRepository()
    fun loadProfile() { repo.getUser() }
}

Anzeichen für SRP-Verletzung: eine Klasse mit mehr als 200 Zeilen, Methoden aus verschiedenen Domänen, häufige Änderungen aus unterschiedlichen Gründen. Für die Android-Entwicklung gilt die einfache Regel: Activity behandelt nur den Bildschirmlebenszyklus, ViewModel behandelt den UI-Zustand, Repository behandelt die Datenquellen.

SRP und Microservice-Architektur

Das SRP-Prinzip gilt nicht nur für Klassen, sondern auch für die Architektur auf Service-Ebene. Jeder Microservice behandelt eine Domänenentität: UserService — nur Benutzer, PaymentService — nur Zahlungen, NotificationService — nur Benachrichtigungen. Dies ermöglicht unabhängiges Skalieren, Bereitstellen und Testen von Diensten. In mobilen Anwendungen zeigt sich SRP auf Microservice-Ebene in der Trennung von API-Clients nach Domäne.

OCP: Open-Closed Principle

Open-Closed Principle (OCP) — Klassen sollten offen für Erweiterung sein (neues Verhalten kann hinzugefügt werden) und geschlossen für Modifikation (vorhandener Code wird nicht geändert). Dies wird durch Polymorphismus, abstrakte Klassen und Schnittstellen erreicht. Anstatt if-else zu einer vorhandenen Methode hinzuzufügen, wird eine neue Schnittstellenimplementierung erstellt.

Laut Clean Coder Blog, 2014, funktioniert OCP am besten mit dem Strategy-Muster. Wenn eine App beispielsweise verschiedene Zahlungsmethoden (Google Pay, Apple Pay, PayPal) unterstützt, muss dem Zahlungsprozessor kein switch-case hinzugefügt werden. Jede Zahlungsmethode implementiert eine gemeinsame PaymentGateway-Schnittstelle, und ein neues Zahlungssystem wird als neue Klasse hinzugefügt, ohne vorhandene zu ändern.

// ✅ OCP: offen für Erweiterung, geschlossen für Modifikation
interface PaymentGateway {
    fun processPayment(amount: Double): Boolean
}

class GooglePayGateway : PaymentGateway {
    override fun processPayment(amount: Double) = true
}

// Neues Zahlungssystem — ohne Änderung des vorhandenen Codes
class ApplePayGateway : PaymentGateway {
    override fun processPayment(amount: Double) = true
}

LSP: Liskov Substitution Principle

Liskov Substitution Principle (LSP) — das Substitutionsprinzip von Barbara Liskov. Wenn S ein Subtyp von T ist, dann können Objekte des Typs T durch Objekte des Typs S ersetzt werden, ohne die Programmeigenschaften zu ändern. Formal: Eine Funktion, die eine Basisklasse verwendet, sollte mit jeder ihrer Unterklassen korrekt funktionieren. Wenn eine Unterklasse eine Ausnahme wirft, wo die Basisklasse keine wirft — ist LSP verletzt.

Laut Robert C. Martin, 2002, ist LSP das am schwersten zu verstehende SOLID-Prinzip. Das klassische Verletzungsbeispiel ist die Klasse Square, die von Rectangle erbt. Wenn setWidth bei Square sowohl Breite als auch Höhe setzt, erhält Client-Code, der Rectangle-Verhalten erwartet, ein unerwartetes Ergebnis. In der mobilen Entwicklung wird LSP oft beim Vererben von ViewModel verletzt — wenn eine Kind-ViewModel erforderliche Abhängigkeiten hinzufügt.

// ❌ LSP-Verletzung: Square bricht Rectangle-Verhalten
open class Rectangle(open var width: Int, open var height: Int)

class Square(side: Int) : Rectangle(side, side) {
    override var width
        get() = super.width
        set(value) { super.setBoth(value, value) }
}

ISP: Interface Segregation Principle

Interface Segregation Principle (ISP) — Clients sollten nicht von Schnittstellen abhängen, die sie nicht nutzen. Statt einer einzigen „fetten“ Schnittstelle erstellen Sie mehrere schmale, spezialisierte Schnittstellen. Wenn eine Klasse eine Schnittstelle implementiert, aber einige Methoden UnsupportedOperationException werfen oder leer bleiben — ist dies ein klares Zeichen für eine ISP-Verletzung.

Laut DigitalOcean, 2024, ist ISP besonders relevant in der mobilen Entwicklung beim Entwurf von ViewModel und Repository. Statt einer einzigen UserRepository-Schnittstelle mit allen CRUD-Methoden ist es besser, QueryUserRepository (nur Lesen) und CommandUserRepository (Schreiben) zu erstellen. Dann hängt ein Nur-Lese-Client (UI-Element) nur von der Query-Schnittstelle ab und weiß nichts von Schreibmethoden.

// ❌ Große Schnittstelle — Client muss unnötige Methoden implementieren
interface UserOperations {
    fun getUser(id: String): User
    fun saveUser(user: User)
    fun deleteUser(id: String)
    fun exportUsers(): File
}

// ✅ ISP: getrennte Schnittstellen
interface UserReader { fun getUser(id: String): User }
interface UserWriter { fun saveUser(user: User) }
interface UserDeleter { fun deleteUser(id: String) }

DIP: Dependency Inversion Principle

Dependency Inversion Principle (DIP) — High-Level-Module sollten nicht von Low-Level-Modulen abhängen. Beide sollten von Abstraktionen (Schnittstellen) abhängen. Abstraktionen sollten nicht von Details abhängen — Details sollten von Abstraktionen abhängen. Dies ist nicht „Dependency Injection“ (DI), obwohl DI eine häufige Methode zur Implementierung von DIP ist.

Laut Robert C. Martin, 2019, ist DIP die Grundlage von Clean Architecture. ViewModel (High-Level) sollte nicht direkt eine RetrofitApi-Instanz (Detail) erstellen. Stattdessen hängt ViewModel von einer UserRepository-Schnittstelle ab, und die konkrete UserRepositoryImpl mit Retrofit wird durch den Konstruktor übergeben. In Android wird DIP durch Hilt/Dagger oder Koin implementiert: Alle Abhängigkeiten werden durch den DI-Container bereitgestellt.

// ✅ DIP: Module hängt von Abstraktion ab, nicht von Details
class UserRepositoryImpl(
    private val api: UserApi,   // Hängt von Schnittstelle ab
    private val db: UserDao     // Hängt von Schnittstelle ab
) : UserRepository {

    override suspend fun getUser(id: String): User {
        return api.fetchUser(id)
    }
}

// Hilt DI: Details werden durch das DI-Modul verbunden
@Module
object NetworkModule {
    @Provides
    fun provideUserApi(retrofit: Retrofit): UserApi =
        retrofit.create(UserApi::class.java)
}

Anwendung von SOLID in der mobilen Entwicklung

SOLID in der mobilen Entwicklung wird auf allen Ebenen angewendet: von der Anwendungsarchitektur bis zu einzelnen Klassen. In Android-Projekten teilt Clean Architecture den Code in drei Schichten: Domain (Geschäftslogik — unabhängig von Frameworks), Data (Repositories, API, DB) und Presentation (UI, ViewModel). Die Domain-Schicht verwendet SOLID-Prinzipien: Anwendungsfälle (SRP), Repository-Schnittstellen (DIP), Entitätsklassen (OCP + LSP).

Laut Android Developers Guide, 2025, zeigt sich SRP in Android in der Trennung von ViewModel, Repository und Mapper. OCP — beim Hinzufügen neuer Datenquellen durch die DataSource-Schnittstelle. LSP — in der einheitlichen Ergebnisverarbeitung über verschiedene Repositories hinweg. ISP — im CQRS-Ansatz (Trennung von Read/Write-Repositories). DIP — durch Hilt/Koin für Dependency Injection.

Häufige Fehler bei der Anwendung von SOLID

SOLID-Fehler hängen meist mit übermäßiger Code-Verkomplizierung zusammen. Der erste — Befolgen der Prinzipien wörtlich ohne Berücksichtigung des Kontexts. Aufteilung einer UserService-Klasse in 10 Schnittstellen und 15 Klassen nur für ein „sauberes“ ISP ist Overengineering. SOLID ist ein Werkzeug, kein Ziel. Der zweite Fehler — Verwechslung von SRP mit „eine Methode = eine Verantwortung“. Eine Klasse kann mehrere Methoden haben, wenn sie alle zum selben Verantwortungsbereich gehören.

Laut Simple Thread, 2024, der dritte Fehler — Ignorieren von LSP beim Vererben von ViewModel in Android. Wenn die Basis-ViewModel LiveData erwartet, die Kind-ViewModel aber StateFlow verwendet — erhält der auf LiveData abonnierte Client-Code keine Updates. Der vierte — Verletzung von DIP für Tests: RepositoryImpl erstellt direkt eine OkHttpClient-Instanz, was Unit-Tests unmöglich macht.

Die goldene Regel: Wenden Sie SOLID an, wenn es ein echtes Problem löst (häufige Änderungen, Tests Schwierigkeit, Duplikation). Für einfache CRUD-Bildschirme ist die strikte Befolgung aller fünf Prinzipien übertrieben. Für Geschäftslogik, Finanzberechnungen und API-Interaktionen ist SOLID unerlässlich.

Verbindung zwischen SOLID und Clean Architecture

Clean Architecture (Robert C. Martin, 2012) — direkte Anwendung von SOLID auf Anwendungsschichtebene. SRP definiert die Grenzen der Anwendungsfälle (jeder Anwendungsfall — eine Klasse). OCP wird durch Repository-Schnittstellen implementiert (Data Layer kann sich ändern, ohne Domain zu modifizieren). ISP bietet die Trennung des Anwendungsfalls in Input/Output-Grenzen. DIP — Abhängigkeitsrichtung nach innen zur Domain-Schicht. LSP garantiert, dass jede Repository-Implementierung austauschbar ist, ohne Anwendungsfälle zu brechen.