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.
Das Prinzip der einzigen Verantwortung basiert auf folgender Kernaussage:
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:
Der Quellcode wird also gemeinsam in einer Klasse verwaltet.
1public class Mitarbeiter
2{
3 public Guid Id { get; set; }
4 public string Name { get; set; }
5 public string Vorname { get; set; }
6 public string Abteilung { get; set; }
7
8 public void BerechneGehalt()
9 {
10 // Rufe RegulaereStunden ab.
11 // Rufe Ueberstunden ab.
12 // Berechne Gehalt.
13 // Überweise Gehalt.
14 }
15
16 public void ErstelleStundenbericht()
17 {
18 // Rufe RegulaereStunden ab.
19 // Erstelle Stundenbericht.
20 }
21
22 public void SpeichereMitarbeiter()
23 {
24 // Speichere Mitarbeiterdaten.
25 }
26}
Nun stellen wir uns vor, dass die Erstellung von Stundenübersichten und Gehaltsabrechnungen eine gemeinsam genutzte Funktion verwenden, um reguläre Arbeitsstunden zu ermitteln.
1public class MitarbeiterStunden
2{
3 public Guid Id { get; set; }
4 public Guid MitarbeiterId { get; set; }
5 public DateTime Datum { get; set; }
6 public int Stunden { get; set; }
7 public int Ueberstunden { get; set; }
8
9 public int RegulaereStunden()
10 {
11 return Stunden - Ueberstunden;
12 }
13}
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.
1public double RegulaereStunden()
2{
3 return 6 / 5 * Stunden - 5 / 6 * Ueberstunden;
4}
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.
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.
Es gibt verschiedene Lösungen, um dieses Problem zu beheben. Eine davon ist, Methoden und Daten in Klassen auszulagern.
1public class GehaltsBerechner
2{
3 public void BerechneGehalt()
4 {
5 // Rufe RegulaereStunden ab.
6 // Rufe Ueberstunden ab.
7 // Berechne Gehalt.
8 // Überweise Gehalt.
9 }
10}
11
12public class StundenBerichtErsteller
13{
14 public void ErstelleStundenbericht()
15 {
16 // Rufe RegulaereStunden ab.
17 // Erstelle Stundenbericht.
18 }
19}
20
21public class MitarbeiterSpeicherer
22{
23 public void SpeichereMitarbeiter()
24 {
25 // Speichere Mitarbeiterdaten.
26 }
27}
28
29public class MitarbeiterDaten
30{
31 public Guid Id { get; set; }
32 public string Name { get; set; }
33 public string Vorname { get; set; }
34}
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.
1public class MitarbeiterFassade
2{
3 private GehaltsBerechner gehaltsBerechner;
4 private StundenBerichtErsteller stundenBerichtErsteller;
5 private MitarbeiterSpeicherer mitarbeiterSpeicherer;
6
7 public MitarbeiterFassade()
8 {
9 gehaltsBerechner = new GehaltsBerechner();
10 stundenBerichtErsteller = new StundenBerichtErsteller();
11 mitarbeiterSpeicherer = new MitarbeiterSpeicherer();
12 }
13
14 public void BerechneGehalt()
15 {
16 gehaltsBerechner.BerechneGehalt();
17 }
18
19 public void ErstelleStundenbericht()
20 {
21 stundenBerichtErsteller.ErstelleStundenbericht();
22 }
23
24 public void SpeichereMitarbeiter()
25 {
26 mitarbeiterSpeicherer.SpeichereMitarbeiter();
27 }
28}
29
30public class MitarbeiterDaten
31{
32 public Guid Id { get; set; }
33 public string Name { get; set; }
34 public string Vorname { get; set; }
35 public double Gehalt { get; set; }
36 public MitarbeiterStunden MitarbeiterStunden { get; set; }
37}
Es gibt jedoch Entwickler, die bevorzugen, die wichtigsten Methoden näher an die Daten zu koppeln.
1public class Mitarbeiter
2{
3 public Guid Id { get; set; }
4 public string Name { get; set; }
5 public string Vorname { get; set; }
6 public double Gehalt { get; set; }
7 public MitarbeiterStunden MitarbeiterStunden { get; set; }
8
9 private GehaltsBerechner gehaltsBerechner;
10 private StundenBerichtErsteller stundenBerichtErsteller;
11 private MitarbeiterSpeicherer mitarbeiterSpeicherer;
12
13 public MitarbeiterFassade()
14 {
15 gehaltsBerechner = new GehaltsBerechner();
16 stundenBerichtErsteller = new StundenBerichtErsteller();
17 mitarbeiterSpeicherer = new MitarbeiterSpeicherer();
18 }
19
20 public void BerechneGehalt()
21 {
22 gehaltsBerechner.BerechneGehalt();
23 }
24
25 public void ErstelleStundenbericht()
26 {
27 stundenBerichtErsteller.ErstelleStundenbericht();
28 }
29
30 public void SpeichereMitarbeiter()
31 {
32 mitarbeiterSpeicherer.SpeichereMitarbeiter();
33 }
34}