Wir haben ein Verfahren in einer prozeduralen Programmiersprache, das mächtig kompliziert zu verstehen ist. Es geht darum, einen Auftrag anzulegen, so dass dieser Auftrag mit der Geschäftslogik unseres Unternehmens bearbeitet werden kann, mit dem Ziel, ihn zu erledigen. Was genau hinter “Auftrag” und “Geschäftslogik” steckt muss der Diskretion wegen ungenannt bleiben.
Heute habe ich nachvollzogen, wie die Prozedur “LegeAuftragAn” aufgerufen wird: Ausgehend von einem Agenten in LotusNotes schlängelt sich der Ablauf zu der genannten Stelle. Der Notes-Agent selbst ist schon Teil des Ablaufs – er iteriert über alle zu verarbeitenden Datensätze. Der Weg vom Agenten zu “LegeAuftragAn” geht durch drei Scriptlibraries und ist gespickt mit allerlei Wenns und Abers und Fehlerbehandlung und Spezialfällen und auskommentierten Codezeilen. Bis ich an der passenden Stelle bin, ist der Stacktrace acht Stockwerke hoch und man muss mächtig auf dem Kiwief sein, die Stelle nicht zu verpassen.
Kann man das besser machen? Ja, objektorientiert. Wie? Grundlegende Idee: Ein Objekt “Auftrag” hat die Methode “anlegen”. Die Methode sucht den neusten Datensatz und prüft, ob es einen älteren gibt. Wenn es den gibt, dann Rekursion von Auftrag.anlegen, sonst weitermachen. Und der ganze dreckige Rest muss auch umgearbeitet werden, aber das ist nicht der springende Punkt. Kernpunkt ist die bessere Lesbarkeit und damit Wartbarkeit: Der Code “unterhalb” des Einstiegspunkts Auftrag.anlegen erklärt die Details des Anlegens eines Auftrags. Weniger denken, wie es der Maschine gefällt, sondern näher dran sein an den Dingen der Geschäftslogik – das ist der große Vorteil von Objektorientierung. Sie macht Abstraktion greifbar.