Durch Aufteilung der Methoden in Integration und Operation entsteht verständlicherer Code. Dadurch steigt die Effizienz beim Entwickeln und es passieren auch deutlich weniger Fehler. Zwei Kriterien die wir bei der Umsetzung von Kundenprojekten sehr wichtig finden.
Zuletzt habe ich über das Prinzip der gegenseitigen Nichtbeachtung gesprochen. Was in einer Gesellschaft problematisch ist, ist in der Softwareentwicklung hingegen von Vorteil. Deshalb möchte ich hier weitermachen und das darauf aufbauende Integration Operation Segregation Principle, auch IOSP genannt, vorstellen.
Bei diesem Prinzip geht es darum, die Funktionseinheiten, die wir letztes Mal definiert haben in zwei Kategorien einzuteilen. Entweder sie operieren und folgen damit dem Principle of Mutial Oblivion oder sie integrieren, d.h. sie stecken andere Funktionseinheiten zusammen. Integrationen sind damit quasi das Schmiermittel, damit die Zahnräder der Maschine auch richtig laufen. Da Integrationen sich um die Verkettung von Funktionseinheiten kümmern, sind diese Abhängig von diesen. Deshalb ist es wichtig sie so einfach wie möglich zu gestalten. Aus diesem Grund enthalten sie auch keine ‚Logik‘.
Unter ‚Logik‘ ist in diesem Fall folgendes zu verstehen:
- Unäre und binäre (Rechen-)Operationen (wie
+,*,%, …) - Kontrollstrukturen (
if,else,while,for,try/catch, …) - API-Aufrufe (Methoden von Bibliotheken wie Workflow Foundation, NHibernate etc.)
- Ressourcen-Zugriffe (Dateien, Datenbanken etc.)
Operationen hingegen, dürfen ‚Logik‘ enthalten. Sie machen damit quasi die harte Arbeit. Dadurch sind sie deutlich komplizierter als Integrationen. Aus diesem Grund sollten diese so unabhängig wie möglich sein. Womit es ihnen nicht erlaubt ist auf andere Funktionseinheiten, also Operatoren oder Integrationen, zuzugreifen. Durch diese Trennung in Integration und Operation entsteht ein deutlich leichtgewichtigere Umsetzung.
Anmerkung: Bei diesem Text handelt es sich um einen überarbeiteten Repost eines alten Blog-Artikels aus 2015 von mir.