Das Schreiben von Software ist ein kreativer Prozess und die Android-Entwicklung macht da keine Ausnahme. Es geht nicht nur darum, etwas zum Laufen zu bringen, sondern um die Entwicklung von Anwendungen, die wachsen, sich anpassen und über die Zeit hinweg handhabbar bleiben können.

Als Android-Entwickler, der zahlreiche architektonische Herausforderungen erlebt hat, habe ich festgestellt, dass die Einhaltung der SOLID-Prinzipien sogar die verwirrendsten Codebasen in saubere Systeme verwandeln kann. Diese Prinzipien sind nicht abstrakt, sondern resultieren aus Erfahrungen und sind reproduzierbar, um robusten, skalierbaren und wartbaren Code zu schreiben.

Dieser Artikel gibt Einblicke in die Anwendung der SOLID-Prinzipien in der Android-Entwicklung durch reale Beispiele, praktische Techniken und Erfahrungen des Meta-WhatsApp-Teams.

Verständnis der SOLID-Prinzipien

Die SOLID-Prinzipien, vorgeschlagen von Robert C. Martin, sind fünf Designprinzipien für objektorientierte Programmierung, die eine saubere und effiziente Softwarearchitektur garantieren.

• Single-Responsibility-Prinzip (SRP): Eine Klasse sollte nur einen einzigen Grund haben, sich zu ändern.
• Offen-Geschlossen-Prinzip (OCP): Software-Entitäten sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein.
• Liskov-Substitutions-Prinzip (LSP): Subtypen müssen für ihre Basistypen austauschbar sein.
• Schnittstellen-Segregations-Prinzip (ISP): Schnittstellen sollten klientenspezifisch sein und nicht die Implementierung nicht verwendeter Methoden erzwingen.
• Abhängigkeits-Inversions-Prinzip (DIP): Hochrangige Module sollten von Abstraktionen abhängen, nicht von niedrigrangigen Modulen.

Durch die Integration dieser Prinzipien in die Android-Entwicklung können wir Anwendungen erstellen, die einfacher zu skalieren, zu testen und zu warten sind.

Single-Responsibility-Prinzip (SRP): Streamlining von Verantwortlichkeiten

Das Single-Responsibility-Prinzip ist die Grundlage für das Schreiben von wartbarem Code. Es besagt, dass jede Klasse nur eine einzige Verantwortung haben sollte. Ein häufiger Anti-Pattern ist die Betrachtung von Aktivitäten oder Fragmenten als “Gott-Klassen”, die Verantwortlichkeiten von der Benutzeroberfläche bis hin zur Datenabfrage und Fehlerbehandlung übernehmen. Dieser Ansatz macht es zu einem Test- und Wartungs-Albtraum.

Mit dem SRP werden verschiedene Verantwortlichkeiten in verschiedene Komponenten aufgeteilt: beispielsweise in einer App für Nachrichten, erstellen oder lesen von Nachrichten.

class NewsRepository {
fun fetchNews(): List {
// Handles data fetching logic
}
}

class NewsViewModel(private val newsRepository: NewsRepository) {
fun loadNews(): LiveData {
// Manages UI state and data flow
}
}

class NewsActivity : AppCompatActivity() {
// Handles only UI rendering
}

Jede Klasse hat nur eine Verantwortung; daher ist es einfach, sie zu testen und zu modifizieren, ohne Nebeneffekte zu haben.

In der modernen Android-Entwicklung wird das SRP meistens zusammen mit der empfohlenen Architektur unter Verwendung von Jetpack implementiert. Beispielsweise kann die Logik, die mit der Datenmanipulation zu tun hat, innerhalb des ViewModels residieren, während die Aktivitäten oder Fragmente sich nur um die Benutzeroberfläche und Interaktionen kümmern sollten. Die Datenabfrage kann an ein separates Repository delegiert werden, entweder aus lokalen Datenbanken wie Room oder Netzwerkschichten wie Retrofit. Dies reduziert das Risiko von UI-Klassen-Überlastung, da jede Komponente nur eine Verantwortung hat. Gleichzeitig wird der Code viel einfacher zu testen und zu unterstützen.

Offen-Geschlossen-Prinzip (OCP): Design für Erweiterung

Das Offen-Geschlossen-Prinzip besagt, dass eine Klasse für Erweiterungen offen, aber nicht für Modifikationen sein sollte. Es ist für Android-Anwendungen sinnvoll, da sie ständig aktualisiert und erweitert werden.

Das beste Beispiel für die Anwendung des OCP-Prinzips in Android-Anwendungen sind Schnittstellen und abstrakte Klassen. Beispielsweise:

interface PaymentMethod {
fun processPayment(amount: Double)
}

class CreditCardPayment : PaymentMethod {
override fun processPayment(amount: Double) {
// Implementation für Kreditkarten-Zahlungen
}
}

class PayPalPayment : PaymentMethod {
override fun processPayment(amount: Double) {
// Implementation für PayPal-Zahlungen
}
}

Das Hinzufügen neuer Zahlungsmethoden erfordert keine Änderungen an bestehenden Klassen; es erfordert die Erstellung neuer Klassen. Hier wird das System flexibel und kann skaliert werden.

In Anwendungen, die für Android-Geräte erstellt werden, ist das Offen-Geschlossen-Prinzip sehr nützlich, wenn es um Feature-Toggles und Konfigurationen geht, die dynamisch übernommen werden. Beispielsweise kann eine AnalyticsTracker-Basis-Schnittstelle, die Ereignisse an verschiedene Analyse-Dienste meldet, wie Firebase und Mixpanel, sowie benutzerdefinierte interne Tracker, jede neue Dienst als separate Klasse hinzugefügt werden, ohne dass die bestehenden Klassen geändert werden müssen. Dies hält das Analytics-Modul offen für Erweiterungen – Sie können neue Tracker hinzufügen – aber geschlossen für Modifikationen: Sie müssen keine bestehenden Klassen neu schreiben, wenn Sie einen neuen Dienst hinzufügen.

Liskov-Substitutions-Prinzip (LSP): Gewährleistung der Austauschbarkeit

Das Liskov-Substitutions-Prinzip besagt, dass Subtypen für ihre Basistypen austauschbar sein sollten und das Verhalten der Anwendung nicht geändert werden sollte. In Android ist dieses Prinzip grundlegend für die Entwicklung von wiederverwendbaren und vorhersehbaren Komponenten.

Beispielsweise in einer Zeichen-App:

abstract class Shape {
abstract fun calculateArea(): Double
}

class Rectangle(private val width: Double, private val height: Double) : Shape() {
override fun calculateArea() = width * height
}

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

Sowohl Rectangle als auch Circle können durch eine andere ersetzt werden, ohne dass das System ausfällt, was bedeutet, dass das System flexibel ist und dem LSP folgt.

Betrachten Sie die RecyclerView.Adapter-Subklassen in Android. Jede Subklasse des Adapters erweitert RecyclerView.Adapter<VH> und überschreibt Kernfunktionen wie onCreateViewHolder, onBindViewHolder und getItemCount. Die RecyclerView kann jeden Adapter-Subtyp austauschbar verwenden, solange diese Methoden korrekt implementiert sind und die Funktionalität der App nicht brechen. Hier wird das LSP aufrechterhalten und Ihre RecyclerView kann jeden Adapter-Subtyp nach Belieben ersetzen.

Schnittstellen-Segregations-Prinzip (ISP): Schlank und fokussierte Schnittstellen

In größeren Anwendungen ist es üblich, Schnittstellen mit zu vielen Verantwortlichkeiten zu definieren, insbesondere im Bereich von Netzwerk oder Datenbank. Stattdessen sollten sie in kleinere, fokussiertere Schnittstellen aufgeteilt werden. Beispielsweise sollte eine ApiAuth-Schnittstelle, die für Benutzer-Authentifizierungs-Endpunkte verantwortlich ist, von einer ApiPosts-Schnittstelle getrennt werden, die für Blog-Beiträge oder soziale Feed-Endpunkte verantwortlich ist. Diese Trennung verhindert, dass Clients, die nur die post-bezogenen Methoden benötigen, gezwungen werden, von und Implementierungen von Authentifizierungsanrufen abhängig zu sein, wodurch der Code sowie die Testabdeckung schlanker werden.

Das Schnittstellen-Segregations-Prinzip bedeutet, dass anstelle einer großen Schnittstelle mehrere kleinere, fokussiertere Schnittstellen verwendet werden sollten. Das Prinzip verhindert Situationen, in denen Klassen unnötige Methoden implementieren.

Beispielsweise anstelle einer großen Schnittstelle, die Benutzeraktionen repräsentiert, kann man in Kotlin-Code:

interface Authentication {
fun login()
fun logout()
}

interface ProfileManagement {
fun updateProfile()
fun deleteAccount()
}

Klassen, die diese Schnittstellen implementieren, können sich nur auf die Funktionalität konzentrieren, die sie benötigen, wodurch der Code sauberer und wartbarer wird.

Abhängigkeits-Inversions-Prinzip (DIP): Abstraktion von Abhängigkeiten

Das Abhängigkeits-Inversions-Prinzip fördert die Entkopplung, indem es sicherstellt, dass hochrangige Module von Abstraktionen abhängen, anstatt von konkreten Implementierungen. Dieses Prinzip stimmt perfekt mit den modernen Android-Entwicklungspraktiken überein, insbesondere mit Abhängigkeits-Injektions-Frameworks wie Dagger und Hilt.

Beispielsweise:

class UserRepository @Inject constructor(private val apiService: ApiService) {
fun fetchUserData() {
// Fetches user data from an abstraction
}
}

Hier UserRepository hängt von der Abstraktion ApiService ab, was es flexibel und testbar macht. Dieser Ansatz ermöglicht es uns, die Implementierung zu ersetzen, beispielsweise durch die Verwendung eines Mock-Dienstes während des Testens.

Frameworks wie Hilt, Dagger und Koin erleichtern die Abhängigkeits-Injektion, indem sie eine Möglichkeit bieten, Abhängigkeiten an Android-Komponenten zu liefern, wodurch die Notwendigkeit, sie direkt zu instantiieren, eliminiert wird. In einem Repository beispielsweise anstelle der Instantiierung einer Retrofit-Implementierung wird eine Abstraktion injiziert – beispielsweise eine ApiService-Schnittstelle. Auf diese Weise können Sie die Netzwerk-Implementierung leicht ersetzen – beispielsweise durch einen in-Memory-Mock-Dienst für lokale Tests – und müssen nichts in Ihrem Repository-Code ändern. In realen Anwendungen können Sie finden, dass Klassen mit @Inject oder @Provides annotiert sind, um diese Abstraktionen bereitzustellen, wodurch Ihre App modular und testfreundlich wird.

Praktische Vorteile der SOLID-Prinzipien

Die Anwendung der SOLID-Prinzipien in der Android-Entwicklung bringt greifbare Vorteile:

1. Verbesserte Testbarkeit: Fokussierte Klassen und Schnittstellen machen es einfacher, Einheitstests zu schreiben.
2. Erhöhte Wartbarkeit: Eine klare Trennung von Verantwortlichkeiten vereinfacht die Fehlersuche und Aktualisierungen.
3. Skalierbarkeit: Modulare Designs ermöglichen eine nahtlose Hinzufügung von Funktionen.
4. Zusammenarbeit: Gut strukturierter Code erleichtert die Zusammenarbeit und reduziert die Einarbeitungszeit für neue Entwickler.
5. Leistungs-Optimierung: Schlank und effiziente Architekturen minimieren unnötige Verarbeitung und Speicherbedarf.

Echte Anwendungen

In funktionsreichen Anwendungen, wie E-Commerce- oder sozialen Netzwerken, kann die Anwendung der SOLID-Prinzipien das Risiko von Rückschlägen verringern, wenn ein neues Feature oder eine neue Dienstleistung hinzugefügt wird. Beispielsweise kann, wenn eine neue Anforderung einen In-App-Kaufprozess erfordert, ein separates Modul erstellt werden, das die erforderlichen Schnittstellen (Zahlung, Analytics) implementiert, ohne die bestehenden Module zu berühren. Dieser modulare Ansatz, der von SOLID getrieben wird, ermöglicht es Ihrer Android-App, sich schnell an Marktanforderungen anzupassen und hält den Code von Spaghetti-Code fern.

Wenn Sie an einem großen Projekt arbeiten, das die Zusammenarbeit vieler Entwickler erfordert, ist es sehr ratsam, einen komplexen Code mit SOLID-Prinzipien zu halten. Beispielsweise half die Trennung von Datenabfrage, Geschäftslogik und Benutzeroberflächen-Handhabung im Chat-Modul, das Risiko von Rückschlägen zu verringern, während der Code mit neuen Funktionen skaliert wurde. Ebenso war die Anwendung des DIP entscheidend, um Netzwerk-Operationen zu abstrahieren, sodass es fast keine Störung gab, wenn der Netzwerk-Client gewechselt wurde.

Schlussfolgerung

Mehr als ein theoretischer Leitfaden sind die SOLID-Prinzipien tatsächlich die praktische Philosophie für die Erstellung von widerstandsfähiger, anpassungsfähiger und wartbarer Software. In der sich schnell bewegenden Welt der Android-Entwicklung, in der Anforderungen fast so oft ändern wie Technologien, bietet die Einhaltung dieser Prinzipien eine feste Grundlage, auf der Erfolg aufgebaut werden kann.

Guter Code ist nicht nur darum bemüht, etwas zum Laufen zu bringen – es geht darum, ein System zu schaffen, das weiterhin funktioniert und mit den sich ändernden Bedürfnissen wächst. Durch die Umarmung der SOLID-Prinzipien schreiben Sie nicht nur besseren Code, sondern bauen auch Anwendungen, die eine Freude sind, zu entwickeln, zu skalieren und zu warten.