SOLID Principles | Single Responsibility C#
TL;DR
Dieser Artikel erklärt das Single Responsibility Principle als Bestandteil der SOLID Principles und zeigt anhand eines C#-Beispiels, warum Klassen nach Verantwortlichkeiten unterschiedlicher Akteure getrennt werden sollten, um Konflikte, unerwartete Seiteneffekte und Wartungsprobleme zu vermeiden.
Single Responsibility Principle
Im Kontext der SOLID Principles beschreibt das Single Responsibility Principle in C#, dass eine Klasse nur dann verändert werden sollte, wenn sich genau ein verantwortlicher Akteur ändert – nicht, wenn unterschiedliche fachliche Zuständigkeiten betroffen sind. Häufig wird es missverstanden. Viele Entwickler interpretieren dieses Prinzip so, dass eine Funktion nur genau eine Sache ausführen darf – also eine große Funktion in kleinere Teilfunktionen zerlegt wird. Dies entspricht jedoch nicht dem SRP.
Leitsatz
Das Prinzip der einzigen Verantwortung basiert auf folgender Kernaussage:
– „Separiere Code dann, wenn verschiedene Akteure davon abhängig sind.“
Beispiel: Ungewollte Abhängigkeiten
Ein Beispiel aus einer Gehaltsabrechnungssoftware liefert die Klasse Mitarbeiter. Sie enthält neben Mitarbeiterdaten drei Methoden:
Hierbei sind drei verschiedene Akteure für die jeweiligen Spezifikationen verantwortlich:
- Die Buchhaltung spezifiziert die Gehaltsberechnung.
- Die Personalverwaltung spezifiziert die Stundenübersicht.
- Die IT-Administration spezifiziert die Speichermethode.
Der Quellcode wird also gemeinsam in einer Klasse verwaltet.
Nun stellen wir uns vor, dass die Erstellung von Stundenübersichten und Gehaltsabrechnungen eine gemeinsam genutzte Funktion verwenden, um reguläre Arbeitsstunden zu ermitteln.
Nun entscheidet die Personalverwaltung, dass die Berechnung regulärer Stunden nach einer neuen Formel erfolgen soll und aktualisiert den Berechnungsalgorithmus – ohne die Buchhaltung darüber zu informieren.
Wenn die Buchhaltung nun zum Monatsende Gehaltsabrechnungen durchführt und der Algorithmus das Gehalt aller Mitarbeiter berechnet, wird die Änderung ohne vorherige Information übernommen.
Die Zahlungen an die Mitarbeiter erfolgen nach dem neuen Berechnungsalgorithmus, was zu einer Erhöhung der Gehaltszahlungen um etwa 20 % führt.
Dieses Szenario ist ein klassisches Beispiel für mangelhafte Modularisierung.
Beispiel: Häufige Konflikte
Nun stellen wir uns vor, dass die Personalverwaltung und die Buchhaltung wegen neuer gesetzlicher Bestimmungen jeweils Änderungen in der Stundenübersicht bzw. Gehaltsabrechnung gleichzeitig durchführen müssen. Beim Zusammenführen beider Versionen in der Versionskontrolle entstehen wahrscheinlich Konflikte, die mühsam gelöst werden müssen, da sich sämtlicher Quellcode in einer Klasse befindet.
Lösung: Methoden auslagern
Es gibt verschiedene Lösungen, um dieses Problem zu beheben. Eine davon ist, Methoden und Daten in Klassen auszulagern.
Der Vorteil dieser Herangehensweise ist eine unabhängige Wartbarkeit. Allerdings müssen zur Laufzeit drei Klassen instanziiert und verwaltet werden.
Eine Lösung bietet das Fassade-Entwurfsmuster. Die Klasse MitarbeiterFassade enthält wenig Quellcode und ist dafür zuständig, untergeordnete Klassen zu instanziieren und deren Methoden zu delegieren.
Es gibt jedoch Entwickler, die bevorzugen, die wichtigsten Methoden näher an die Daten zu koppeln.
Diese Prinzipien entfalten ihren Wert vor allem in langlebigem Code. Wir helfen Unternehmen dabei, ihre Legacy-Software zu modernisieren, schrittweise und im laufenden Betrieb.
