Objektorientierung als Wissenstransfer

Ich mache mir recht viele Gedanken darüber, welche Struktur meine Anwendungen haben sollen. Weil in Quellcode soviel Arbeit steckt wird einmal geschriebener Code immer weiter gereicht, manchmal über 3 oder 4 Teams hinweg, die nichts voneinander wissen. Damit der Wissenstransfer trotzdem funktioniert muss der Quellcode verständlich sein. Im folgenden Beitrag soll das Konzept der Objektorientierung anhand eines Negativbeispiels erklärt werden. Ich versichere Ihnen, dass ich mir dieses Beispiel nicht ausgedacht habe.

Wenn darum geht Dinge aus der tatsächlichen Welt „in den Computer zu bringen“, d.h. ein Modell dieser Dinge zu bauen, dann sind für mich Programmiersprachen die von vornherein mit Blick auf das Konzept der Objektorientierung geschrieben wurden und eine statische Typisierung bieten die erste Wahl.

Nehmen wir zwei Arten von IDs. Die eine Art von IDs benennt ein Team, die andere einen Raum oder ein Gebäude. Beide lassen sich semantisch nicht unterscheiden, d.h. ich kann eine ID von jeder Art aufschreiben und beide können gleich sein. Technisch gesehen sind beide Arten von IDs übrigens Zeichenketten (Strings).

Einer der Fehler, den ich selbst gesehen habe: Beide Arten von IDs wurden in einer Anwendung als Zeichenketten herumgereicht. Weil sie technisch gesehen nichts weiter als Zeichenketten zu sein scheinen. Nun gab es in der Software eine Funktion, die ein Team anhand anderer Merkmale als der ID finden konnte. Was aber wenn kein Team gefunden wurde? Dann gab die Funktion „nichts“ (null) zurück.

Als dies in der Anwendung zu Fehlern führte (NullPointerException), wurde die Funktion so geändert, dass versucht wurde anhand der Suchkriterien den Raum zu finden in dem sich das Team aufhielt. In diesem Fall wurde dann statt der Team-ID die Raum-ID zurückgegeben. Das war möglich denn die Funktion gab ja nur eine Zeichenkette zurück.

Früher oder später wird diese Änderung natürlich zu Verwirrung und Fehlern führen. Wie gesagt ich kann anhand der ID nicht sehen, ob es sich um eine Team-ID oder Raum-ID handelt. Es wird viel Geld kosten um das wieder zu richten.

Wenn sich zwei Menschen über IDs unterhalten, dann wissen wir ja welche Art gemeint ist, entweder aus dem Kontext des Gespräches oder sie verständigen sich ausdrücklich darüber („Sprechen wir über eine Team- oder eine Raum-ID?“). Aber der Computer weiß das nicht! Noch schlimmer: Nicht eingeweihte Entwickler wissen es auch nicht!

Wir geben also unser Menschen-Wissen in den Computer ein indem wir für beide Arten von IDs je eine Klasse zu erstellen:
A. TeamID
B. EstateID (für Grundstücke, Räume, usw.)

Beide Klassen scheinen nichts gemeinsam zu haben, oder doch? Beide sind doch IDs nicht wahr? Welches Verhalten haben IDS gemeinsam?

IDs können normalerweise validiert werden. Daher haben sie eine Definition von Validität – sie können valide sein oder nicht. Ich würde jetzt ein Interface namens AnyID hinzufügen und diesem die Methode isValid(): boolean mitgeben. Jetzt haben IDs etwas gemeinsam: Sie sind validierbar. Und wissen jetzt nicht nur Sie und ich sondern auch alle anderen Entwickler Bescheid!

Die Validierbarkeit von Objekten ist überall dort lebenswichtig, wo Objete über Systemgrenzen weiter gereicht werden. Jedes System muss sicher stellen, dass sie eingegebenen Daten valide sind, damit der Versucht sie zu verarbeiten nicht mit einem undefinierten Zustand endet. (Eine leere ID? – Hilfe!!!)

Nun können AnyID weitere Gemeinsamkeiten hinzugefügt werden. Bitte nur solche, die auch wirklich allen IDs gemeinsam sind. Möglich ist es auch, isValid: boolean in ein neues Interface zu verschieben das allen validierbaren Objekten zu eigen gemacht werden kann. Wenn nun AnyID aber gar keine Methoden mehr hat, dann gibt es keine Gemeinsamkeiten zwischen beiden IDs! Und dann muss AnyID weg! Un dann weiß wieder jeder Entwickler Bescheid, dass IDs eben keine Gemeinsamkeiten haben.

Zum Lesen:
[1] Ralf Westphal: OOP as have you meant it, JavaSpektrum 3/2015
Dieser Artikel hat mich vor schlimmen Fehlern bezüglich der Objektorierung bewahrt und mich dazu gebracht mehr von Alan Kay zu lesen.

Alan Kay gilt als derjenige, den den Begriff „Objektorientierung“ geprägt hat. Hier sind seine Gedanken dazu – und was Objektorientierung seiner Meinung nach eben nicht ist:
[2] http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented
[3] http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

Auf dieser Seite beschäftigt sich jemand sehr gründlich mit dem Lebenswerk und den Gedanken Alan Kays an sich:
[4] http://mythz.servicestack.net/blog/2013/02/27/the-deep-insights-of-alan-kay/

 

Veröffentlicht in InGerman, ObjectOrientation, Uncategorized. Schlagwörter: , . Kommentare deaktiviert für Objektorientierung als Wissenstransfer
%d Bloggern gefällt das: