Architektur und Patterns in der mobilen Entwicklung: Was sie sind, welche es gibt und wie man sie anwendet

Wichtige Architekturmuster

Ein Architekturmuster bestimmt, wie Verantwortlichkeiten zwischen den Anwendungsklassen verteilt werden. Die Wahl des Musters beeinflusst, wie einfach es ist, neue Bildschirme hinzuzufügen und Code zu testen.

MVC (Model-View-Controller)

MVC ist ein klassisches Muster, bei dem Model für Daten, View für die Anzeige und Controller für die Logik zuständig ist. In iOS ist MVC der Standard (UIViewController), in Android Activity. Der Nachteil ist, dass der Controller oft „massiv" wird (Massive View Controller). Laut einer iOS-Entwicklerumfrage (Reddit, 2025) geben 62% MVC als Hauptursache für unlesbaren Code in Legacy-Projekten an.

MVP (Model-View-Presenter)

MVP unterscheidet sich dadurch, dass der Presenter die View über eine Schnittstelle verwaltet, was die Testbarkeit verbessert. MVP war vor Jetpack in Android beliebt, bleibt aber in Bezug auf den Komfort hinter MVVM zurück.

MVVM (Model-View-ViewModel)

MVVM ist das von Google für Android und von Apple für iOS empfohlene Muster. Das ViewModel speichert den Zustand, und die View abonniert Änderungen über Data Binding oder @Published. Das ViewModel ist unabhängig von der View und leicht zu testen. Bei IT Sectr verwenden wir MVVM als Hauptmuster in allen Projekten.

MVI und VIPER

MVI ist ein reaktives Muster, bei dem jede Aktion dem Zyklus Intent → Model → View folgt. MVI garantiert einen vorhersagbaren Zustand. VIPER ist ein iOS-Muster mit fünf Schichten (View, Interactor, Presenter, Entity, Router), das maximale Isolation bietet, aber viel Boilerplate-Code erfordert.

Clean Architecture

Clean Architecture ist das Konzept von Robert Martin, das eine Anwendung in Schichten unterteilt: äußere Schichten (UI, DB, Netzwerk) hängen von inneren Schichten (Geschäftslogik, Entitäten) ab. In der mobilen Entwicklung umfasst Clean Architecture drei Schichten: data (Repositories), domain (Use Cases) und presentation (ViewModels, UI).

Repository Pattern ist eine Schlüsselkomponente von Clean Architecture, die die Datenquelle abstrahiert. Das Repository entscheidet, ob Daten aus dem Netzwerk oder dem lokalen Speicher (Room, Core Data) geholt werden, und gibt ein einheitliches Format zurück. Laut Google (Architecture Guide, 2025) wird Repository Pattern für jede App mit Netzwerkanfragen empfohlen. Clean Architecture ist bei Projekten mit 3–5 Bildschirmen oder mehr gerechtfertigt — für einfache Apps beginnen Sie mit MVVM.

Erzeugungsmuster

Singleton

Singleton ist ein Architekturmuster, das eine einzige Instanz einer Klasse garantiert und einen globalen Zugriffspunkt darauf bereitstellt. Es wird für Datenbanken, Einstellungsmanager und Caches verwendet. In Kotlin wird es über object erstellt. Der Nachteil ist, dass es aufgrund des globalen Zustands das Testen erschwert.

Factory und Builder

Factory delegiert die Objekterstellung an eine Factory-Methode — statt new rufen Sie die Factory auf. Builder ist ein schrittweises Konstruktionsmuster für komplexe Objekte mit vielen Parametern (AlertDialog.Builder, NotificationCompat.Builder). Builder verbessert die Lesbarkeit und ermöglicht es, Objekte nach dem Zusammenbau unveränderlich zu halten.

Struktur- und Verhaltensmuster

Adapter, Facade, Delegate, Protocol

Adapter ist ein Architekturmuster, das die Schnittstelle einer Klasse in eine vom Client erwartete Schnittstelle umwandelt. In Android ist dies RecyclerView.Adapter. Facade bietet eine vereinfachte Schnittstelle zu einem komplexen System — zum Beispiel eine Fassade für eine API, die Authentifizierungsdetails verbirgt. Delegate ist ein iOS-Muster, bei dem ein Objekt eine Aufgabe delegiert (UITableViewDelegate). Protocol ist das Äquivalent einer Schnittstelle in Swift.

Observer und Strategy

Observer ist ein Abonnementmuster für Änderungen: Das Subjekt benachrichtigt Abonnenten über Aktualisierungen. In der mobilen Entwicklung bildet Observer die Grundlage von LiveData, StateFlow, RxJava und Combine. Strategy ist ein Muster für austauschbare Algorithmen: Sie stecken eine andere Strategie ein (Sortierung, Validierung) ohne mehrere if-else-Anweisungen.

Abhängigkeitsinjektion und Zustandsverwaltung

Dependency Injection ist ein Architekturmuster, bei dem ein Objekt seine Abhängigkeiten von außen erhält, anstatt sie selbst zu erstellen. Statt new Database() übergeben Sie die Datenbank über den Konstruktor. DI vereinfacht Tests — Sie können einen Mock anstelle einer echten Datenbank verwenden — und erleichtert den Austausch von Implementierungen. Beliebte DI-Frameworks: Dagger und Hilt (Android), Swinject (iOS), Koin (Kotlin). Hilt — ein von Google empfohlener Wrapper über Dagger — reduziert den DI-Setup um das Dreifache.

Service Locator ist eine Alternative zu DI mit einer zentralen Registrierung von Abhängigkeiten. Einfacher zu implementieren, verbirgt aber Klassenabhängigkeiten, was das Testen erschwert. Moderne Projekte bevorzugen DI über Hilt oder Koin.

Zustandsverwaltung in Flutter

In Flutter ist die Zustandsverwaltung ein eigenes Ökosystem. Redux — ein einzelner Store mit Änderungen über Actions → Reducer → State. BLoC von Google trennt Ereignisse und Zustände über Stream. Provider — ein einfacher DI-Container, der von Google für Flutter bis 2023 empfohlen wurde. Riverpod — ein verbesserter Provider, der Kompilierungs- und Testprobleme löst. GetX — ein Micro-Framework mit Routing, DI und Zustandsverwaltung. Für Anfänger in Flutter empfehlen wir Provider oder Riverpod als die am besten dokumentierten Lösungen.

SOLID- und DRY-Prinzipien

Neben spezifischen Mustern gibt es allgemeine Architekturdesignprinzipien, die in jeder Sprache und jedem Framework anwendbar sind.

SOLID — fünf Prinzipien des objektorientierten Designs: Single Responsibility (eine Klasse — eine Aufgabe), Open-Closed (offen für Erweiterung, geschlossen für Änderung), Liskov Substitution (Unterklassen ersetzen die Elternklasse), Interface Segregation (kleine Schnittstellen), Dependency Inversion (Abhängigkeit von Abstraktionen). In der mobilen Entwicklung ist SRP das nützlichste Prinzip: Jede Klasse tut nur eine Sache. Nach Erfahrung von IT Sectr ist die Verletzung von SRP die Ursache für 70% der Testprobleme in kommerziellen Projekten.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

Das Kotlin-Beispiel zeigt, wie wir eine UserManager-Klasse mit vier Verantwortlichkeiten in vier Klassen mit jeweils einer Verantwortlichkeit umwandeln. Solcher Code ist einfacher zu testen, zu ändern und wiederzuverwenden.

DRY (Don't Repeat Yourself) — vermeiden Sie Code-Duplizierung. Extrahieren Sie wiederholte Logik in gemeinsame Methoden oder Klassen. KISS (Keep It Simple, Stupid) — Einfachheit ist wichtiger als Eleganz. YAGNI (You Aren't Gonna Need It) — schreiben Sie keinen Code für etwas, das möglicherweise nicht benötigt wird. Diese Prinzipien helfen, sauberen, wartbaren Code ohne Redundanz zu schreiben.

Android-Plattformmuster

ViewModel (Android) ist eine Jetpack-Architekturkomponente zum Speichern des UI-Zustands, resistent gegen Bildschirmrotation. ViewModel enthält keine Verweise auf Activity und wird automatisch bereinigt. LiveData — ein beobachtbarer Datencontainer mit Lebenszyklus-Bewusstsein. StateFlow — ein moderner Ersatz für LiveData basierend auf Kotlin Flow. SharedFlow — ein Hot Flow für einmalige Ereignisse (Navigation, Toasts).

Data Binding und Two-Way Binding — Mechanismen zum Binden von UI und Daten in Android. Data Binding deklariert die Verbindung in XML; Two-Way Binding aktualisiert automatisch das Feld im ViewModel. Unidirectional Data Flow — ein Prinzip, bei dem Daten in eine Richtung fließen: State → UI → Event → State. Bei IT Sectr verwenden wir Unidirectional Data Flow in allen neuen Projekten — es reduziert die Anzahl von Fehlern durch unerwartete Zustandsänderungen.