Kohäsion in der mobilen Entwicklung: Grundlagen, Stufen und Verbesserung

Was ist Kohäsion

Kohäsion ist eine Metrik, die bewertet, wie logisch Methoden, Felder und Eigenschaften innerhalb einer Klasse oder eines Moduls miteinander verbunden sind. Ein hoch kohäsives Modul führt eine Aufgabe aus und enthält nur die Elemente, die zu deren Erfüllung notwendig sind. Ein niedrig kohäsives Modul versucht, mehrere Dinge gleichzeitig zu tun — seine Methoden sind in ihrer Bedeutung schwach miteinander verbunden.

Im Kontext der objektorientierten Programmierung ist Kohäsion eng mit dem Single-Responsibility-Prinzip (S) verbunden. Wenn eine Klasse eine klare Verantwortung hat, ist ihre Kohäsion in der Regel hoch. Wenn eine Klasse sich mit UI, Geschäftslogik und Netzwerk gleichzeitig befasst — ist die Kohäsion niedrig, und eine solche Klasse sollte in mehrere separate Klassen mit engeren Verantwortlichkeiten aufgeteilt werden.

Das Verständnis von Kohäsion hilft Entwicklern bei Refactoring-Entscheidungen. Wenn Sie in einer Klasse eine Methode sehen, die keines der Felder der Klasse verwendet, ist das ein Zeichen niedriger Kohäsion. Eine solche Methode ist entweder falsch in der Klasse platziert, oder die Klasse ist schlecht entworfen. Das Streben nach hoher Kohäsion ist eine kontinuierliche Bemühung, die Architektur auf jeder Codeebene zu verbessern.

Arten und Stufen der Kohäsion

Im Software Engineering werden sieben Kohäsionsstufen unterschieden, von der schlechtesten zur besten geordnet. Das Verständnis dieser Skala ermöglicht es, die Qualität eines Moduls objektiv zu bewerten und die Richtung für das Refactoring zu bestimmen. Je höher die Stufe, desto wartbarer und verständlicher wird der Code sein.

Niedrige Kohäsion: zufällige, logische und zeitliche

Zufällige — die schlechteste Stufe, bei der Elemente in einem Modul zufällig ohne logische Verbindung gruppiert werden. Beispiel: eine Utilities-Klasse mit Methoden zur Datumsformatierung, E-Mail-Versand und Rabattberechnung. Eine solche Klasse kann nicht verstanden werden, ohne alle ihre Methoden zu lesen, und das Ändern einer Methode könnte andere brechen, nur weil sie zusammen sind.

Logische — Elemente führen logisch verwandte, aber grundlegend unterschiedliche Aufgaben aus. Eine Klasse mit Methoden parseJSON, parseXML und parseCSV ist logisch durch das Thema „Parsen“ verbunden, aber jede Methode macht grundlegend unterschiedliche Arbeit. Das Problem: Wenn ein neues Format (YAML) hinzugefügt wird, wächst die Klasse und ihre Schnittstelle wird aufgebläht.

Zeitliche — Elemente werden nach Ausführungszeit gruppiert. Eine AppInitializer-Klasse, die die Datenbank einrichtet, Konfiguration lädt und Analysen initialisiert — all dies geschieht beim App-Start, aber die Aufgaben selbst sind nicht miteinander verbunden. Besser ist es, sie in separate Initializer für jeden Verantwortungsbereich aufzuteilen.

Mittlere Kohäsion: prozedurale und kommunikative

Prozedurale — tritt auf, wenn Elemente durch eine Ausführungssequenz verbunden sind. Ein Modul „Auftragsverarbeitung“ enthält Methoden validateCart, processPayment und sendConfirmation — jede Methode wird streng nach der vorherigen aufgerufen. Dies ist besser als zufällige oder logische Kohäsion, aber noch nicht ideal: jeder Schritt könnte in ein separates Modul extrahiert werden.

Kommunikative — Elemente arbeiten mit denselben Daten. Eine UserService-Klasse mit Methoden getUser, updateUser und deleteUser ist durch die gemeinsame User-Entität verbunden. Dies ist wesentlich besser als prozedurale Kohäsion: die Klasse hat eine klare Domäne. Die meisten Repository-Klassen in mobilen Projekten haben kommunikative Kohäsion.

Hohe Kohäsion: funktionale

Funktionale — die höchste Stufe, bei der jedes Element des Moduls an der Ausführung einer einzigen Aufgabe beteiligt ist. Eine PasswordValidator-Klasse mit einer einzigen validate-Methode, die Länge, Zeichenvorhandensein und Passwortkomplexität prüft — ein Beispiel für funktionale Kohäsion. Wenn sich eine solche Klasse ändert, dann nur, weil sich die Passwortvalidierungsregeln geändert haben.

Das Erreichen funktionaler Kohäsion ist das Hauptziel des architektonischen Refactorings. Jede Klasse sollte genau einen Grund für eine Änderung haben. In der mobilen Entwicklung wird funktionale Kohäsion durch die Extraktion separater Use Cases, benutzerdefinierter Views, Formatierer und Validierer erreicht. Jede solche Klasse ist ein vollständiger Baustein mit einem klaren Verantwortungsbereich.

Kohäsion vs Kopplung

Kohäsion und Kopplung sind zwei Seiten derselben Qualität. Je höher die Kohäsion innerhalb eines Moduls, desto niedriger ist in der Regel die Kopplung zwischen Modulen. Ein gut entworfenes System strebt gleichzeitig nach hoher interner Kohäsion und loser externer Kopplung. Dieses Prinzip wird seit den 1970er Jahren als grundlegend im Software Engineering anerkannt.

Die Kohäsions-Kopplungs-Beziehung kann als Gleichgewicht betrachtet werden. Wenn ein Entwickler Kohäsion opfert, indem er mehrere Aufgaben in einer Klasse kombiniert, erhalten benachbarte Module mehr Abhängigkeiten — sie müssen auf diese überladene Klasse für verschiedene Zwecke zugreifen, was die Kopplung erhöht. Umgekehrt reduziert die Aufteilung in kleine, hoch kohäsive Klassen die Anzahl der Interaktionspunkte zwischen Modulen.

In der Praxis bedeutet dies: Wenn Sie eine neue Klasse mit funktionaler Kohäsion extrahieren, befreien Sie gleichzeitig andere Module von der Notwendigkeit, die Details ihrer Implementierung zu kennen. Beispielsweise gibt die Extraktion von EncryptionManager in eine separate Klasse mit funktionaler Kohäsion anderen Modulen eine einfache encrypt/decrypt-Schnittstelle, ohne dass sie die Details des Verschlüsselungsalgorithmus verstehen müssen.

// Niedrige Kohäsion — die Klasse macht alles auf einmal
class UserManager {
    fun fetchAndSaveUser(id: String) { }
    fun parseUserJson(json: String): User { }
    fun displayUserName(user: User): String { }
    fun validateEmail(email: String): Boolean { }
}

// Hohe Kohäsion — jede Klasse löst eine Aufgabe
class UserRepository {
    fun fetchUser(id: String): User { }
}

class UserJsonParser {
    fun parse(json: String): User { }
}

class UserNameFormatter {
    fun format(user: User): String { }
}

class EmailValidator {
    fun isValid(email: String): Boolean { }
}

Das Beispiel zeigt den Unterschied: UserManager hat logische Kohäsion — alle Methoden befassen sich mit Benutzern, aber jede macht grundlegend unterschiedliche Arbeit. Nach dem Refactoring hat jede Klasse funktionale Kohäsion, und die Kopplung wird reduziert, weil andere Module nur von der Klasse abhängen, die sie benötigen, nicht vom gesamten UserManager.

Wie man Kohäsion im Code misst

LCOM (Mangel an Kohäsion von Methoden) ist die bekannteste Metrik zur Messung der Klassenkohäsion. LCOM zählt, wie viele Methodenpaare keine gemeinsamen Felder teilen. Ein Wert von 0 bedeutet ideale Kohäsion (alle Methoden arbeiten mit denselben Feldern), während ein hoher Wert niedrige Kohäsion anzeigt. LCOM4 (eine verbesserte Version) berücksichtigt transitive Verbindungen über andere Methoden.

In der Android-Entwicklung können Kohäsionsmetriken durch Detekt mit der Regel TooManyFunctions ermittelt werden. Klassen mit Dutzenden von Methoden, die verschiedene Feldgruppen verwenden, haben wahrscheinlich niedrige Kohäsion. In iOS hat SwiftLint die Regeln file_length und function_body_length — indirekte Indikatoren: lange Dateien und Methoden signalisieren oft niedrige Kohäsion.

Eine manuelle Bewertungsmethode: Stellen Sie die Frage „Wird sich diese Klasse aus einem Grund oder aus mehreren Gründen ändern?“ Wenn Sie mehr als einen unabhängigen Grund nennen können — hat die Klasse niedrige Kohäsion. Ein zweiter Test: „Kann diese Klasse in zwei unabhängige Klassen aufgeteilt werden?“ Wenn ja — tun Sie es. Die regelmäßige Überprüfung der Kohäsion bei Code-Reviews verhindert Gott-Klassen und reduziert technische Schulden.

Wie man Kohäsion in einem mobilen Projekt verbessert

Erster Schritt — wenden Sie das Single-Responsibility-Prinzip an. Jede Klasse sollte eine klare Verantwortung haben. Wenn eine Klasse eine Methode enthält, die nicht zu ihrer Hauptaufgabe gehört, extrahieren Sie sie in eine separate Klasse. Die Extract Class- oder Extract Delegate-Technik in IDEs automatisiert diesen Prozess. Überprüfen Sie nach der Extraktion, ob die ursprüngliche Klasse fokussierter geworden ist.

Zweiter Schritt — verwenden Sie das Facade-Muster, um die Schnittstelle zu vereinfachen. Wenn eine Klasse 20 Methoden bereitstellt, Kunden aber nur 3–4 verwenden, hat die Klasse möglicherweise niedrige Kohäsion — sie bietet zu viele verschiedene Funktionen. Gruppieren Sie Methoden nach Thema, extrahieren Sie separate Klassen für jede Gruppe und machen Sie die ursprüngliche Klasse zu einer Fassade oder entfernen Sie sie.

Dritter Schritt — achten Sie auf Feldgruppen. Wenn eine Klasse Felder hat, die nur von einer Teilmenge der Methoden verwendet werden — ist das ein Indikator für niedrige Kohäsion. Teilen Sie die Klasse nach Feldgruppen auf. Wenn eine Klasse beispielsweise die Felder userRepository, networkClient und analyticsTracker enthält, aber die erste Methodengruppe nur userRepository verwendet, während die zweite networkClient verwendet — sind das zwei verschiedene Klassen.

Vierter Schritt — vermeiden Sie die Erstellung von „Utility“-Klassen mit willkürlichen static-Methoden. Jede static-Methode in einer Utils- oder Helpers-Klasse ist ein Kandidat für die Extraktion in eine spezialisierte Klasse. FormatUtils.dateToString sollte besser in DateFormatter verschoben werden, und ValidationUtils.isValidEmail in EmailValidator. Dies erhöht die Kohäsion jeder Klasse und macht den Code selbst dokumentierend.