Zwischen Integration und Operation trennen
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.

Kevin Erath
Geschäftsführer
Veröffentlicht am
26. Dezember 2020

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.

Hier schreibt
Kevin Erath
Als Mitbegründer und Geschäftsführer von pep.digital verbringe ich zwar nicht mehr jeden Tag ausschließlich damit, coole Lösungen für unsere Kunden zu realisieren. Trotzdem finde ich immer wieder die Zeit, mich auch mal tiefer in die Technik einzutauchen und meine Erkenntnisse hier im Blog zu teilen. Und ehrlich gesagt, das Unternehmen und unsere tollen Mitarbeiter:innen weiterzuentwickeln, macht mir mindestens genauso viel Spaß.
Quellen
Weitere interessante Artikel
Wir möchten hier nicht nur über Neuigkeiten aus dem Unternehmen berichten, sondern auch das Wissen und die Erfahrung unserer Experten teilen.

Ausnahmen im Code mit Roslyn finden
Mit Hilfe von Roslyn lässt sich sehr einfach der Code analysieren. In diesem Beispiel werden alle Methoden ermittelt, die eine Exception schmeißen.

Kevin Erath
Geschäftsführer

Peer blickt auf 1 Jahr pep.digital zurück
Peer ist seit einem Jahr bei pep.digital tätig. Als Software Entwickler sorgt er für stabile Lösungen in unseren Projekten. Das Schöne für ihn bei pep.digital ist, dass er den Bereich sehr individuell gestalten und prägen kann. Detaillierte Informationen zu seiner aktuellen Arbeit, was er an pep.digital am meisten schätzt und worauf er in seinem Werdegang besonders stolz ist erzählt er im Beitrag.
pep.digital