SOLID-Prinzipien in Kotlin: Theorie und Praxis für sauberen Code

Einleitung: Warum SOLID in Kotlin wichtig ist

SOLID ist ein Akronym für fünf fundamentale Prinzipien der objektorientierten Programmierung, formuliert von Robert Martin. Im Kontext von Kotlin, einer modernen Multiplattform-Sprache, gewinnen diese Prinzipien besondere Bedeutung. Kotlin vereint sowohl OOP- als auch funktionale Möglichkeiten, was das Schreiben von flexiblerem und wartbarerem Code ermöglicht. Die Einhaltung der SOLID-Prinzipien hilft Entwicklern, Systeme zu erstellen, die leicht skalierbar, testbar und wartbar sind.

In diesem Artikel werden wir jedes der fünf Prinzipien anhand konkreter Beispiele in Kotlin analysieren, von der Theorie bis zur praktischen Umsetzung. Sie erfahren, wie Sie typische Antipatterns vermeiden und Ihren Code sauberer gestalten können.

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

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

Praxis in Kotlin: Oft verletzen Entwickler das SRP, indem sie in einer Klasse die Logik zur Datenverarbeitung, Validierung und Arbeit mit externen Diensten unterbringen.

Beispiel für eine Verletzung:

class UserManager {    fun saveUser(user: User) {        // Speichern in der Datenbank        println("User saved to DB")    }

    fun sendEmail(user: User, message: String) {        // E-Mail senden        println("Email sent to ${user.email}")    }

    fun validateUser(user: User): Boolean {        // Datenvalidierung        return user.name.isNotEmpty()    }}

Hier ist UserManager für das Speichern, das Senden von E-Mails und die Validierung verantwortlich. Wenn sich die Logik zum Senden von E-Mails ändert, müsste diese Klasse geändert werden, was das Speichern von Daten beeinträchtigen könnte.

Korrigierte Variante mit SRP:

class UserRepository {    fun save(user: User) {        println("User saved to DB")    }}

class EmailService {    fun send(user: User, message: String) {        println("Email sent to ${user.email}")    }}

class UserValidator {    fun validate(user: User): Boolean {        return user.name.isNotEmpty()    }}

Jetzt hat jede Klasse eine einzige Verantwortung, was das Testen und die Änderung des Codes vereinfacht.

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

Theorie: Software-Entitäten (Klassen, Module, Funktionen) sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein. Das bedeutet, dass Sie in der Lage sein sollten, neues Verhalten hinzuzufügen, ohne vorhandenen Code zu ändern.

Praxis in Kotlin: Verwenden Sie Abstraktionen (Schnittstellen oder abstrakte Klassen) und Polymorphismus. In Kotlin eignen sich dafür besonders sealed class und when-Ausdrücke.

Beispiel für eine Verletzung:

class AreaCalculator {    fun calculate(shape: Any): Double {        return when (shape) {            is Circle -> Math.PI * shape.radius * shape.radius            is Square -> shape.side * shape.side            else -> throw IllegalArgumentException("Unknown shape")        }    }}

Um eine neue Form (z. B. Triangle) hinzuzufügen, müsste die Methode calculate modifiziert werden.

Korrigierte Variante mit OCP:

interface Shape {    fun area(): Double}

class Circle(private val radius: Double) : Shape {    override fun area() = Math.PI * radius * radius}

class Square(private val side: Double) : Shape {    override fun area() = side * side}

class Triangle(private val base: Double, private val height: Double) : Shape {    override fun area() = 0.5 * base * height}

class AreaCalculator {    fun calculate(shape: Shape) = shape.area()}

Jetzt reicht es aus, eine neue Klasse zu erstellen, die das Interface implementiert, um eine neue Form hinzuzufügen.