Solid Reihe - Single Responsibility Principle
Single Responsibility Principle
Das Single Responsibility Principle ist eines der am wenigsten verstandenen Prinzipien der SOLID-Grundsätze. 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.
public class Mitarbeiter
{
public Guid Id { get; set; }
public string Name { get; set; }
public string Vorname { get; set; }
public string Abteilung { get; set; }
public void BerechneGehalt()
{
// Rufe RegulaereStunden ab.
// Rufe Ueberstunden ab.
// Berechne Gehalt.
// Überweise Gehalt.
}
public void ErstelleStundenbericht()
{
// Rufe RegulaereStunden ab.
// Erstelle Stundenbericht.
}
public void SpeichereMitarbeiter()
{
// Speichere Mitarbeiterdaten.
}
}
Nun stellen wir uns vor, dass die Erstellung von Stundenübersichten und Gehaltsabrechnungen eine gemeinsam genutzte Funktion verwenden, um reguläre Arbeitsstunden zu ermitteln.
public class MitarbeiterStunden
{
public Guid Id { get; set; }
public Guid MitarbeiterId { get; set; }
public DateTime Datum { get; set; }
public int Stunden { get; set; }
public int Ueberstunden { get; set; }
public int RegulaereStunden()
{
return Stunden - Ueberstunden;
}
}
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.
public double RegulaereStunden()
{
return 6 / 5 * Stunden - 5 / 6 * Ueberstunden;
}
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.
public class GehaltsBerechner
{
public void BerechneGehalt()
{
// Rufe RegulaereStunden ab.
// Rufe Ueberstunden ab.
// Berechne Gehalt.
// Überweise Gehalt.
}
}
public class StundenBerichtErsteller
{
public void ErstelleStundenbericht()
{
// Rufe RegulaereStunden ab.
// Erstelle Stundenbericht.
}
}
public class MitarbeiterSpeicherer
{
public void SpeichereMitarbeiter()
{
// Speichere Mitarbeiterdaten.
}
}
public class MitarbeiterDaten
{
public Guid Id { get; set; }
public string Name { get; set; }
public string Vorname { get; set; }
}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.
public class MitarbeiterFassade
{
private GehaltsBerechner gehaltsBerechner;
private StundenBerichtErsteller stundenBerichtErsteller;
private MitarbeiterSpeicherer mitarbeiterSpeicherer;
public MitarbeiterFassade()
{
gehaltsBerechner = new GehaltsBerechner();
stundenBerichtErsteller = new StundenBerichtErsteller();
mitarbeiterSpeicherer = new MitarbeiterSpeicherer();
}
public void BerechneGehalt()
{
gehaltsBerechner.BerechneGehalt();
}
public void ErstelleStundenbericht()
{
stundenBerichtErsteller.ErstelleStundenbericht();
}
public void SpeichereMitarbeiter()
{
mitarbeiterSpeicherer.SpeichereMitarbeiter();
}
}
public class MitarbeiterDaten
{
public Guid Id { get; set; }
public string Name { get; set; }
public string Vorname { get; set; }
public double Gehalt { get; set; }
public MitarbeiterStunden MitarbeiterStunden { get; set; }
}Es gibt jedoch Entwickler, die bevorzugen, die wichtigsten Methoden näher an die Daten zu koppeln.
public class Mitarbeiter
{
public Guid Id { get; set; }
public string Name { get; set; }
public string Vorname { get; set; }
public double Gehalt { get; set; }
public MitarbeiterStunden MitarbeiterStunden { get; set; }
private GehaltsBerechner gehaltsBerechner;
private StundenBerichtErsteller stundenBerichtErsteller;
private MitarbeiterSpeicherer mitarbeiterSpeicherer;
public MitarbeiterFassade()
{
gehaltsBerechner = new GehaltsBerechner();
stundenBerichtErsteller = new StundenBerichtErsteller();
mitarbeiterSpeicherer = new MitarbeiterSpeicherer();
}
public void BerechneGehalt()
{
gehaltsBerechner.BerechneGehalt();
}
public void ErstelleStundenbericht()
{
stundenBerichtErsteller.ErstelleStundenbericht();
}
public void SpeichereMitarbeiter()
{
mitarbeiterSpeicherer.SpeichereMitarbeiter();
}
}
Gemeinsam Großes schaffen
Tibor Csizmadia
