Mit dem Prinzip der eindeutigen Verantwortlichkeit zur Objektorientierung für Embedded Entwickler
Das Single Responsibility Prinzip (SRP) ist auf Deutsch das Prinzip der eindeutigen Verantwortlichkeit. Auf den ersten Blick erscheint es einfach, ist im Detail aber spannend. Dieses Prinzip gibt eine erste Regel, wie ein System in Teilsysteme zu schneiden ist.
Dies ist der zweite Teil einer Artikelserie von Carsten Pitz zur objektorientierten Programmierer für Embedded Entwickler (Teil 1).
Single Responsibility Prinzip (SRP)
Ein Objekt (Sachbearbeiter) bietet genau eine, wohl-definierte, möglichst eng geschnittene Dienstleistung an. In diesem Sinne ist ein Micro-Service ein über Web-Interface anzusprechendes Objekt. Diese Isomorphie wird, als Vorgriff auf Teil 6 nochmals beim Interface Segregation Prinzip (ISP) deutlich sichtbar.
Dabei ist zu beachten, dass Objekte autonom agieren. Autonomie impliziert in sich abgeschlossen. In sich abgeschlossen bedeutet jedoch nicht, nutzt keine Dienstleistungen anderer Objekte. Ein Objekt darf, soll sogar Dienstleistungen anderer Objekte nutzen um redundante Implementierungen zu vermeiden und um die Objekte möglichst einfach und klein zu halten.
Je einfacher ein Objekt ist, desto weniger Fehlerquellen bietet es und umso einfacher ist es zu Testen.
Wie gesagt, Objekte dürfen, sollen sogar Dienstleistungen anderer Objekte nutzen. Dies führt zu Abhängigkeiten zwischen Objekten. Diese Abhängigkeiten sind auf der gleichen Art und Weise wie durch die strukturierte Programmierung gewohnt durch Schichtung zu strukturieren. Ein Objekt darf nur Objekte in der gleichen Schicht, auf Objekte der nächst-tieferen Schicht oder auf querschnittliche Objekte nutzen.
Komplexität eines Systems
Das Single Responsibility Prinzip (SRP) senkt nicht die Komplexität eines Systems. Die Komplexität eines Systems ist eine Eigenschaft des Systems selbst, gegeben durch die Gesamtheit der expliziten und impliziten Anforderungen an das System sowie des Kontextes mitsamt Schnittstellen zu angrenzenden Systemen. Zum Beispiel bestimmt bei Reglern typischerweise das zu regelnde System die Komplexität.
Die Systemkomplexität lässt sich nur durch die Anforderungslage beeinflussen. Nicht ohne Grund ist Automotive SPICE der Arbeitsschritt ENG.1 mit „Auswahl der Anforderungen“ benannt. Auswahl bedeutet nicht blind übernehmen.
Zerlegung in Teilsysteme
Wie bei einer Jacke der Schnitt nur unwesentlich die benötigte Stoffmenge beeinflusst, jedoch maßgeblich bestimmt wie bequem sich die Jacke trägt, ändert der Schnitt eines Systems in Teilsyteme die Realisierungskomplextität nur unwesentlich, aber bestimmt wie gut sich das Gesamtsystem beherrschen lässt.
Die Realisierungskomplextität ist stets höher als die Systemkomplexität. Zum Einen durch die Schnitte, die Schnittstellenbeschreibungen erfordern. Zum Anderen aufgrund von Redundanzen in der Realisierung.
Hier zeigt sich ein weiterer Trade-Off auf, Schnitte erhöhen die Realisierungskomplextität durch die notwendigen Schnittstellenbeschreibungen, bieten aber zugleich das Potential, die Realisierungskomplextität durch vermeiden von Redundanzen zu senken.
Im Verlauf des Artikels gebe ich Hinweise, wie dieser Trade-Off aussehen kann. Ich habe bewusst nicht „sollte“ sondern „kann“ gewählt, da es hier kein Richtig oder Falsch gibt. Verschiedene Lösungen sind evtl. mehr oder weniger elegant, aber nicht grundsätzlich richtig oder falsch.
Fazit
Ein Teilsystem soll durch eine möglichst allgemein verständliche Metapher beschrieben werden können. Die Metapher soll eine Dienstleistung beschreiben. Fachliche Dienstleistungen sollen in Kundensprache (z.B. Signalausleuchtung), technische Dienstleistungen hingegen mit technischen Begriffen (z.B. Logbuch) beschrieben werden.
Im etwa einem Monat wird der dritte Teil veröffentlicht, in dem das Open-closed Prinzip (OCP) behandelt wird.
Bis dahin freue ich mich auf viele Fragen und Diskussionen im Kommentarbereich.
Photo by Nikolai Chernichenko on Unsplash
