ALLINSIGHT

Home of the AlmostImplementedException

Nullobjekt

Wie in meinem vorherigen Beitrag über Einführung in Entwurfsmuster angekündigt, werde ich mit dem ersten konreten Beitrag über das “Null Objekt” beginnen. Dafür werden ich das Schachbrett-Beispiel aus Indizierte Eigenschaften heranziehen.
Was ist das “Null Objekt”? Es ist ein Entwurfsmuster, welches zu den Verhaltensmustern zählt. Das Objekt tut nichts. Es ist repräsentativ für nichts. Das folgende UML Diagramm sollte dessen einfache Struktur erläutern.

Null Object (UML)

So, warum nehmen wir nicht einfach null anstelle eines Null-Objekts? Ein Grund ist, dass wir damit “Null Reference Exceptions” vermeiden. Ein weiterer Vorteil ist die Verwendung des Nullobjekts in Verbindung mit dem “Visitor Pattern” (Ich werde dies in einem kommenden Beitrag erklären). Schauen wir uns das nun an einem praktischen Beispiel an. In unserer Schachbrett Beispiel benutzen wir indizierte Eigenschaften, um an die entsprechenden Felder des Schachbrettes zu kommen. Wir werden also zunächst die Klasse “Field” mit etwas Leben füllen. Aber vorher schauen wir uns die aktuelle Field-Klasse an.

Ich bin der Meinung, dass die ToString Methode ein wenig einsam wirkt – Also fügen wir einfach noch ein paar Dinge hinzu. Wir nehmen eine neue Eigenschafft die wir “Value” nennen und einen Wert vom Typen der neuen Klasse “Figure” enthält. Diese Klasse ist abstract, da wir die Konkreten Schachfiguren von ihr ableiten. Des Weiteren fügen wir die entsprechende Initialisierung der “Board” Klasse hinzu. Wir werden das in einem Schritt machen (Entschuldigt daher den langen Code, aber ich denke es ist besser, wenn wir eine gemeinsame Code Base für die folgenden Schritte haben). Wir ignorieren vorerst das Verhalten jeder einzelnen Figur in unserem Beispiel, wie z.B. Start und End-Position, Bewegungsvalidierung etc. weil wir uns auf die Struktur konzentrieren wollen – Außerdem wollte ich euch ja etwas über das Nullobjekt erzählen 😉

Nun ist unserer Schachbrett mit den Figuren an ihrer Initialposition gefüllt und wir können einfach “ExecuteAction” aufrufen für die Figur bei “C2”. Ihr werden feststellen, dass wir “I’m a Pawn’ als Ausgabe erhalten.

Aber ist passiert, wenn wir “ExecuteAction” für “C3” aufrufen? Wir werden eine NullReferenceException erhalten, weil sich auf diesem Feld keine Figur befinden. Um das zu verhindern, müssen wir auf “null” prüfen.

Ich denke wir stimmt mir zu, dass des nicht gerade ein eleganter Weg ist. Das ist der Punkt, wo das Nullobjekt in’s Spiel kommt.
Wir müssen dafür foldende zwei Dinge tun: Erzeugen einer “Empty”-Klasse, die von “Figure” erbt. Und “Empty” allen Feldern zuweisen, die keinen Wert haben. In unserem Beispiel übernimmt das die “Reset”-Methode, in der wir die Figuren erstellen/zuweisen.

Jetzt sind wir in der Lage auf ein Feld ohne Figur “ExecuteAction” aufzurufen – und es passiert einfach nichts.

Vielleicht werden ihr denken: “Zuviel Aufwand – Auf null prüfen wird auch ausreichen”. Ja ich stimme euch zu, aber sobald euer Code immer komplexer wird, und ihr diese Objekte an viele Stellen verwendet, müsst ihr überall immer wieder auf “null” prüfen – und es kann sehr leicht passieren, dass ihr das irgendwo vergesst 😉
In einem kommenden Beitrag über “Entwurfsmuster” werde ich über das “Visito Pattern” schreiben, was ein sehr guter Anschluss zu diesem Beitrag ist.
Ich hoffe euch hat der Beitrag gefallen. Bis zum nächsten Mal!

Share :

, , , , ,

Leave a Reply