Immer ehrlich programmieren
Java Januar 23rd, 2008Mich hat heute etwas rund drei Stunden Lebenszeit gekostet und ich weiß noch nicht ob ich sauer sein sollte – und wenn ja, auf wen.
Die Ursache: In einer verteilten Anwendung gibt es Objekte, die eine lokale Repräsentation haben, und zusätzlich entfernt gespeichert werden. Bei der entfernten Speicherung gibt es für jedes Objekt eine Identität die durch eine „ID“ repräsentiert wird und ein paar Daten.
Für die lokale Speicherung gibt es eine Identität die durch eine – nicht notwendigerweise gleiche – „ID“ repräsentiert wird und auch Daten.
Praktischerweise gibt es Attribute die nur lokal oder nur bei der remote Version des Objektes vorhanden sind. Um teure Remoteaufrufe zu sparen wird nicht immer die Vereinigungsmenge der Attrbute gebildet, sondern in der Regel mit der lokalen Objektversion gearbeitet.
Alles halb so schlimm, alles ist schön gekapselt in mindestens drei Schichten und ordentlich Interface, Framework und Library Watte. Wehe jedoch man weicht von etablierten und getesteten Wegen ab, das kann ein schreckliches Ende nehmen.local = mapRemoteToLocalObject( remoteService.getObject( local.getId()))
So in etwa sieht das dann aus. An einer klitzekleinen Stelle wird hier leider etwas gelogen. Wie bereits erwähnt gibt es eigentlich zwei IDs für das Objekt – die lokale und die – genauso echte – entfernte. Versucht man nun ein entferntes Objekt mit der lokalen ID zu holen, und hat blöderweise auch noch Testdaten die das zulassen ohne das gleich Tod und Teufel an der Tür stehen, kann man viel Zeit verbringen bis man der Sache auf die Spur kommt.local = mapRemoteToLocalObject( remoteService.getObject( local.getRemoteId()))
Ist dann das Ergebnis des Abends.
Ein Glück, dass die Testdaten nicht noch schlechter waren – der Fehler hätte locker übersehen werden können.
Womit ich auf den Punkt komme: Ehrliches Programmieren bedeutet Code, der erstens wie Fließtext lesbar ist – und zweitens dabei nichts suggeriert, was nicht stimmt.
Neue Kommentare