Die SOLID-Prinzipien zielen darauf ab, objektorientierte Software langfristig wartbarer zu machen. In meinem Blog widme ich jedem der fünf Prinzipien einen eigenen Beitrag.
- Single Responsibility Principle
- Open-Closed Principle
- Liskov-Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Das Single Responsibility Principle (SRP) ist ein Entwurfsprinzip von Robert C. Martin. Es bildet zusammen mit vier anderen Prinzipien das Akronym SOLID und steht für dessen ersten Buchstaben. Es hat folgende Aussage:
each software module should have one and only one reason to change
Robert C. Martin
Robert C. Martin hat dieses Statement 2014 in einem Blogbeitrag wie folgt konkretisiert:
Gather together the things that change for the same reasons. Separate those things that change for different reasons.
Robert C. Martin
Reason to Change
Was ist nun ein Reason to Change? Robert C. Martin schlüsselt dies in seinem Blogbeitrag auf und sieht in erster Linie Menschen als Änderungsgrund. Als Beispiel führt er ein Stück Code an, das einen Mitarbeiter repräsentiert und mehrere Funktionen bereitstellt, die unterschiedlichen Verantwortungsbereichen zugeordnet werden können. So könnte die Gehaltsabrechnung für den Mitarbeiter vom Finanzvorstand verantwortet werden und die Zeiterfassung vom Betriebsvorstand.
Meine Auffassung
Ich stimme der Kernaussage zu. Hinter einem Änderungsgrund stecken immer Menschen. Das Beispiel ist mir aber nicht differenziert genug.
Die drei gegebenen Funktionen Gehaltsabrechnung, Zeiterfassung und Personaldatenverwaltung würde wohl kaum jemand in eine gemeinsame Einheit verpacken, schon weil sie aufgrund ihrer jeweiligen Komplexität äußerst selten überhaupt in einer gemeinsamen Anwendung anzutreffen sein dürften.
Für einen Änderungsgrund kommen weitaus mehr Personen infrage, als nur die Verantwortungsträger in einer Organisationsstruktur:
- Ein externer Partner ändert seine Schnittstellen
- Eine Gesetzesänderung macht Anpassungen in der Software notwendig
- Anpassungen werden aufgrund von Kundenwünschen vorgenommen
- Allgemeine Trends oder technische Fortschritte führen zu Anpassungen
- Eine Software wird agil inkrementell weiterentwickelt; anfangs einfache Prozesse werden mit der Zeit komplizierter
Hinter all diesen Änderungsgründen kann als direkte Schnittstelle zu den Entwicklern der gleiche Product Owner stehen. Dem Entwickler ist unter Umständen gar nicht bekannt, dass es eine Gesetzesänderung geben wird oder ein Partner seine alte Schnittstelle abgekündigt hat. Er hat vielleicht auch gar nicht im Blick, welche Stakeholder es alle gibt, da der Product Owner als Fassade dazwischen steht, die Anforderungen bündelt und die Priorisierungen vornimmt.
Ein Änderungsgrund kann aus meiner Sicht erstmal alles sein und das macht es sehr schwierig zu sagen, was nun in eine gemeinsame Einheit gehören kann und was man besser trennen sollte.
Ich würde mir immer die Frage stellen, welche Verantwortung eine Einheit hat. Wenn ich merke, dass ich dies nicht mit wenigen Worten formulieren kann oder dass ich mehrfach das Wort und verwenden muss, dann ist meine Einheit vermutlich zu groß geschnitten. Bildet eine Klasse eine logische Einheit gut ab, spricht man auch von hoher Kohäsion. Ziel des SRP ist es also, eine hohe Kohäsion zu erreichen.
Ich finde es aber auch wichtig, das Prinzip nicht zu strikt auszulegen, da dies ebenso die Entwicklung erschweren kann. Man sollte auch immer im Blick haben, wie viele Einheiten angepasst werden müssen, wenn eine Änderungsanforderung umgesetzt wird. Führen vermeintlich simple fachliche Anpassungswünsche dazu, dass sehr viele Einheiten angepasst werden müssen, so hat man seine Einheiten zu kleinteilig geschnitten.
- Blogartikel zum SRP von Robert C. Martin