Architekturprinzipien in der mobilen Entwicklung: was sie sind, welche es gibt und wie man sie anwendet

SOLID-Prinzipien

Architekturprinzipien — sind die Grundlage für qualitativ hochwertigen Code. SOLID ist ein Akronym, das von Robert Martin („Onkel Bob") eingeführt wurde und fünf Prinzipien des objektorientierten Designs beschreibt. Die Befolgung von SOLID macht Code flexibler, testbarer und widerstandsfähiger gegenüber Änderungen. Die Verletzung von Architekturprinzipien ist eine der Hauptursachen für technische Schulden.

Betrachten wir jedes Prinzip. Single Responsibility Principle (SRP) — jede Klasse sollte nur einen Grund für eine Änderung haben. Open/Closed Principle (OCP) — Klassen sind für Erweiterungen offen, aber für Modifikationen geschlossen. Liskov Substitution Principle (LSP) — Objekte von Untertypen sollten Objekte des Basistyps ersetzen können, ohne die Logik zu brechen. Interface Segregation Principle (ISP) — viele spezialisierte Schnittstellen sind besser als eine allgemeine. Dependency Inversion Principle (DIP) — Abhängigkeit von Abstraktionen, nicht von konkreten Implementierungen.

Laut SonarQube-Analyse (2025) tritt die Verletzung von SOLID-Prinzipien in 68% der kommerziellen Projekte auf. Die häufigsten Probleme sind SRP-Verletzung (35%) und ISP-Verletzung (22%). Bei IT Sectr implementieren wir SOLID in der Architekturüberprüfungsphase — das hilft, Probleme zu erkennen, bevor sie zu technischen Schulden werden.

Single Responsibility Principle (SRP)

SRP (Prinzip der einzigen Verantwortung) — das wichtigste und gleichzeitig das am häufigsten verletzte SOLID-Prinzip. Es besagt: Eine Klasse sollte nur einen Grund für eine Änderung haben. Wenn eine Klasse zu viel tut, ist sie schwer zu testen, zu ändern und zu verstehen.

Ein typischer Verstoß ist eine Klasse, die gleichzeitig Daten verarbeitet, in der Datenbank speichert und E-Mail-Benachrichtigungen sendet. Das folgende Beispiel zeigt eine SRP-Verletzung in Kotlin und wie man sie behebt.

// SRP-Verletzung — Klasse macht drei verschiedene Dinge
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Datenvalidierung
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. In Datenbank speichern
        val user = User(email, name)
        database.save(user)
        
        // 3. Benachrichtigung senden
        emailService.sendWelcomeEmail(email, name)
    }
}

// Behebung — Aufteilung in drei Klassen
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

In der korrigierten Version ist jede Klasse für ihre eigene Aufgabe verantwortlich: UserValidator — für die Validierung, UserRepository — für das Speichern, NotificationService — für Benachrichtigungen. Das macht den Code testbar und wiederverwendbar — Sie können die Datenbankimplementierung ersetzen, ohne die Validierungslogik zu ändern.

GRASP und Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — neun Architekturprinzipien zur Verteilung von Verantwortlichkeiten zwischen Objekten, beschrieben von Craig Larman. Im Gegensatz zu SOLID beantwortet GRASP die Frage „welche Klasse sollte diese Methode enthalten?“. Schlüsselmuster: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, Prinzip der minimalen Kopplung) — eine einfache Regel: Ein Objekt sollte nur mit seinen unmittelbaren Nachbarn kommunizieren. Man sollte nicht a.getB().getC().doSomething() schreiben — das erzeugt eine starke Kopplung zwischen Klassen. LoD verbessert die Wiederverwendbarkeit und vereinfacht das Testen.

Bei IT Sectr überprüfen wir die Einhaltung von LoD bei der Code-Review. Wenn eine Methode drei oder mehr Objekte „durchläuft", ist das ein Signal, dass die Architektur vereinfacht werden muss. LoD-Verletzung ist einer der häufigsten Code Smells in großen Projekten.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) und YAGNI (You Ain't Gonna Need It) — drei grundlegende Architekturprinzipien, die jedem Entwickler bekannt sind. Trotz ihrer Einfachheit kommen Verstöße ständig vor.

DRY — duplizieren Sie keinen Code. Wenn dieselbe Logik an zwei Stellen vorkommt, extrahieren Sie sie in eine gemeinsame Methode oder Klasse. Duplizierung ist die Hauptquelle für Fehler: Eine Korrektur an einer Stelle wird vergessen, an einer anderen angewendet zu werden. DRY bedeutet nicht, dass Sie keinen ähnlichen Code haben können — wichtig ist, dass die Geschäftslogik nicht wiederholt wird.

KISS — je einfacher, desto besser. Komplexe Lösungen mit vielen Abstraktionen und Vererbungen sind oft übermäßig. Beginnen Sie mit einer einfachen Lösung und machen Sie sie nur bei Bedarf komplexer. YAGNI — schreiben Sie keinen Code für Funktionalität, die „irgendwann später" benötigt werden könnte. Das führt zu aufgeblähtem Code und erhöhter Wartungskomplexität.

DRY — Don't Repeat Yourself

DRY — es geht nicht nur um die Abwesenheit von Copy-Paste. Es ist ein Prinzip, nach dem jedes Wissens- oder Logikstück eine einzige, eindeutige Darstellung im System haben sollte. Duplizierung kann explizit (kopierter Code) und implizit (gleiche Logik in verschiedenen Schichten) sein.

Bei IT Sectr verwenden wir Code-Analyse-Metriken, um Duplizierung zu erkennen. Tools wie SonarQube und Detekt zeigen den Prozentsatz duplizierten Codes. Ein Wert über 5% ist ein Grund für Refactoring. Es ist jedoch wichtig zu bedenken: DRY sollte nicht um den Preis falscher Abstraktionen erreicht werden — manchmal ist es besser, zwei ähnliche Code-Stücke so zu belassen, wenn ihre Kombination das Verständnis erschweren würde.

Separation of Concerns und Modularität

Separation of Concerns (SoC) — ein Architekturprinzip, bei dem ein System in unabhängige Teile (Concerns) aufgeteilt wird, die jeweils ihre eigene Aufgabe lösen. Ein klassisches Beispiel ist die Schichtentrennung: Präsentation, Geschäftslogik, Datenzugriff. Jede Schicht hängt nur von der darunter liegenden ab.

Modularität — der Grad, in dem ein System in Module zerlegt werden kann. Ein Modul ist eine logisch zusammenhängende Gruppe von Klassen mit einer klar definierten Schnittstelle. Module sollten lose gekoppelt (low coupling) und stark kohäsiv (high cohesion) sein.

Kohäsion vs Kopplung

Kohäsion — ein Maß dafür, wie sehr Elemente innerhalb eines Moduls miteinander verbunden sind. Hohe Kohäsion ist gut: Eine Klasse macht eine Sache und macht sie gut. Niedrige Kopplung — ein Maß dafür, wie unabhängig Module voneinander sind. Niedrige Kopplung ist gut: Die Änderung eines Moduls zerbricht andere nicht.

Ideale Architektur ist hohe Kohäsion und niedrige Kopplung. In der Praxis bedeutet das: Eine Klasse enthält Methoden, die auf denselben Daten arbeiten (Kohäsion), und hängt nur von Abstraktionen ab, nicht von konkreten Implementierungen (Kopplung). Ein Ungleichgewicht führt zu „God Objects" oder „Spaghetti-Code".

Technische Schulden und Code Smell

Technische Schulden (Technical Debt) — eine von Ward Cunningham eingeführte Metapher, die die „Zinsen" beschreibt, die ein Team für suboptimale Architekturentscheidungen und Verletzung von Architekturprinzipien zahlt. Wie finanzielle Schulden können technische Schulden beabsichtigt (wir haben uns entschieden, es schnell zu machen, wir machen es später neu) und unbeabsichtigt (schlechte Architektur aufgrund mangelnder Erfahrung) sein.

Code Smell — oberflächliche Anzeichen für tiefgreifende Probleme im Code. Der Begriff wurde von Martin Fowler in seinem Buch „Refactoring" populär gemacht. Typische Code Smells: lange Methoden, große Klassen, lange Aufrufketten, Code-Duplizierung, übermäßige Verwendung von Kommentaren (anstelle von klarem Code).

Bei IT Sectr werden technische Schulden in Jira als separate Aufgaben verfolgt. Jeden Sprint widmen wir 20% der Zeit für Refactoring und Schuldenrückzahlung. Systematische Arbeit mit technischen Schulden ist der einzige Weg, um eine Situation zu vermeiden, in der das Hinzufügen einer neuen Funktion länger dauert als die Entwicklung von Grund auf.