Kommunikation

Ein wichtiger Aspekt beim Design von Methoden wie myLife() ist die Kommunikation. Übergabeparameter und Rückgabetyp sucht man ja vergebens - weiß also am Anfang nicht, was rein kommt und am Ende bleibt sowieso nichts außer eine Menge vollgeschriebener Speicher, den ein GarbageCollector dann einsammeln muss.

Doch dazwischen gibt es zum Glück Wege und Methoden - eigentlich natürlich nur Methoden - mit der Funktionsumgebung in Kontakt zu treten. Eine wichtige ist die abstracte Klasse Friends, von der zu Beginn der Abarbeitung von myLife eine leere Liste von Objekten angelegt wird, die sich aber mit der Zeit mehr oder weniger schnell füllt (und freilich auch wieder leert). Über die in dieser Liste enthaltenen Objekte, die auch in anderen Kontexten als myLife verfügbar sind) kann der Systemkontext positiv auf myLife einwirken - die Pflege dieser Liste ist also von großer Bedeutung und sollte keinesfalls außer Acht gelassen werden, ermöglichen sie doch eine Bereicherung des Funktionsumfangs von myLife. 

Der Clou ist nämlich, dass alle in der Liste referenzierten Instanzen über eine völlig eigene Implementierung der Methode communicate(Obejct audience), die in Friends noch abstrakt deklariert wird, verfügen. MyLife() kann diese dann nutzen um sich auf verschiedenste Arten mit der Systemumwelt in Verbindung. 

Listing 1

Übergeben wir nun als audience mit Persönlichkeit das zentrale Objekt aus myLife(), so können wir mit allen Instanzen vom Typ Friends unterschiedlich kommunizieren. Dabei wird eine gewichtige Einschränkung jedoch deutlich: die eigene Persönlichkeit muss die passenden Methoden bereitstellen, sonst nutzen die besten Freunde nichts.

Big Ball of Mud

Von wegen das Leben schreibt die besten Geschichten. Für mich steht fest: das Leben schreibt Spaghetticode. 

Man denkt alles läuft in geordneten Bahnen und die nächsten Verzweigungen sind klar, aber dann kommt auf einmal eine Sprunganweisung ins Nichts daher und man hat keine Ahnung, wo man landet. 

Wegwerfen und komplett neu schreiben rät der geschulte Informatiker, doch leider geht das bei Leben nicht so leicht, da beim Deployment auf eine strikte Trennung von Produktiv- und Entwicklungssystem verzichtet wurde. Und auch wenn man versucht alles sinnvoll in Modulen zu strukturieren, irgendeine globale Variable zerschießt einem doch wieder die ganze Architektur. 

private List<Feelings> relationship(); ist da ein schönes Beispiel. Die Funktion arbeitet zentral mit den globale definierten Objekten you und me. Nun hat aber you die dumme Angewohnheit, sich völlig unberechenbar zu verhalten (und auch auf den Zustand von me sollte man sich nie verlassen). In der originalen Version von relationship() finden sich jedoch keinerlei Sicherungsmechanismen, die etwaige Ausnahmen sinnvoll behandeln können. Hier wird dringend empfohlen, auf null-pointer zu prüfen und von Try-Catch-Konstrukten regen Gebrauch zu machen. Doch auch damit ist man nicht vor unerwarteten Fehlern in relationship() gefeit, daher sollte auch deren Aufruf stets unter kontrollierten Bedingungen erfolgen, will man fatale Ausnahmesituationen vermeiden.