GOOS – Gedanken zum ersten Teil

Wow! Obwohl es sich beim ersten Teil doch eher um eine Einführung und Wiederholung der Themen TDD, OOD und Mocks handelt, habe ich eine Menge neuer Dinge gelernt. Bei einigen bin ich mir allerdings noch nicht 100% sicher, ob ich die Konzepte wirklich verstanden habe. Der erste Teil des Buchs besteht aus einer Einleitung, einem Kapitel über “What is the Point of TDD”, einem über “TDD with Objects” und ein kurzer Überblick der Tools die im Buch zum Einsatz kommen.

Objektgeflecht

In meinem letzten Blog-Post habe ich bereits über das Warum? bezüglich TDD geschrieben. Das darauffolgende Kapitel über “TDD with Objects” war äußerst interessant. Es betont die Wichtigkeit zu verstehen, dass es bei OOP nicht um die Objekte selbst sondern vielmehr um die Kommunikation zwischen diesen Objekte geht. Es entsteht ein Objektgeflecht, dass für das Verhalten des Systems maßgeblich verantwortlich ist. Dieses Verhalten kann man natürlich beeinflussen indem man dieses Netz aus kollaborierenden Objekten konfiguriert: Mit welchen Objekten ist ein Objekt verbunden; Objekte können ausgetauscht werden; Komplette Objektkompositionen können ersetzt und neu konfiguriert werden. Es handelt sich dabei um eine deklarative Vorgehensweise wie wir das Verhalten unseres Systems beeinflussen.

Objektgeflecht

Values und Objekte

Ich persönlich tue mir hin und wieder noch etwas schwer den Unterschied zwischen Objekten und reinen Werten zu unterscheiden. Auch hierzu bietet das Buch einen gesonderten Abschnitt zu dieser Thematik. Der Punkt, dass beide Varianten in vielen OOP Sprachen vom selben Konstrukt, nämlich einer Klasse, gebildet werden, trägt zum Verständnis nicht unbedingt bei. Eines ist jedoch ganz klar, wir teilen unser System in zwei Teile. Der eine Teil besteht aus unveränderlichen Werten und der andere aus Objekten die eine eigene Identität besitzen und somit den Zustand des Systems repräsentieren.

image

Kommunikationsmuster

Wie bereits erwähnt, ist die Kommunikation zwischen Objekten das wichtigste Konstrukt in einem OOP System. Die entstehenden Kommunikationspfade können mit Hilfe von so genannten Communication Patterns organisiert werden. Genau diese Muster bilden die eigentliche Domäne des Systems ab (im Gegensatz zum statischen Konstrukt der Klasse). Diese Denkweise ist auch für mich relativ neu und wird noch einiges an Übung erfordern um komplett von mir verstanden zu werden. Noch dazu wird das Domänenmodell verschleiert, da diese Kommunikationsmuster kein eigenes Konstrukt in einer derzeitigen OOP Sprache darstellen. Um diese Thematik besser verstehen zu lernen, wird auf das Buch von Rebecca Wirfs-Brock “Object Design: Roles, Responsibilities and Collaborations” verwiesen.

Tell, don’t ask!

Ein weiterer wichtiger Punkt ist das Law of Demeter bzw. der “Tell, don’t ask”-Style. Dabei geht es darum, dass Objekte aufgrund ihres eigenen Zustands Entscheidungen treffen sollen. Objekte sollten nicht aufgrund des Zustands anderer Objekte Entscheidungen treffen. Dadurch können “Train wreck” Konstrukte vermieden werden, was dazu führt, dass wir nicht nur Information Hiding unterstützen, sondern auch die Kommunikation zwischen Objekten explizit machen. Anders ausgedrückt, ein Objekt muss ganz genau sagen was es erreichen möchte und nicht wie.

Natürlich gibt es wie bei fast allen Richtlinien auch hier Ausnahmen. Das Abfragen von Werten oder Collections ist natürlich erlaubt. Hin und wieder müssen sogar richtige Objekte nach ihrem Zustand gefragt werden. Dabei sollte dem passendsten Objekt die Abfragemethode hinzugefügt und der Name der Methode so ausdrucksstark wie möglich formuliert werden. Solche Methoden sollten aber nur sparsam eingesetzt werden, da sonst das System unflexibel werden kann.

Mock-Objekte

Daraus folgt natürlich die Frage: Ok, ich soll also meinen Objekten sagen was sie tun sollen und nicht irgendwelche Eigenschaften abfragen. Aber wie teste ich dann ein Objekt das nur Kommandos besitzt und keine Rückgabewerte? Das ist der Zeitpunkt indem die Rolle der Mock-Objekte eingeführt wird. Im Buch wird das von den Autoren entwickelte Mocking-Framework JMock propagiert. Jedoch egal welches Framework verwendet wird, der wichtigste Punkt welcher beachtet werden sollte ist folgender:

Die Intention eines Tests sollte immer klar zum Ausdruck gebracht werden. Dabei muss eindeutig zwischen der zu testenden Funktionalität, der notwendigen Infrastruktur und der Objektstruktur unterschieden werden.

Über sageniuz

https://about.me/ClausPolanka
Dieser Beitrag wurde unter Clean Code, GOOS veröffentlicht. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s