Seite 4: Fazit

Inhaltsverzeichnis

Fazit

Das Einführen des Value Object hat den Code modularisiert und die Projektsprache bereichert. Das Aufteilen des Codes förderte Erweiterbarkeit, Wartbarkeit und Verständlichkeit der Software. Auch die Invarianten ließen sich aufteilen, was ebenfalls zur Verständlichkeit der Software und seiner Anforderungen beigetragen hat (da es sich bei der Klasse "Kaufvertrag" um ein Domänenobjekt handelt, ist zu bedenken, dass die Zahl der Invarianten und der enthaltenen Geschäftsregeln in einem realen Projekt deutlich größer wäre). Außerdem kommt die Aufteilung der Testbarkeit des Codes zugute. Vor allem das Value Object lässt sich relativ einfach testen, weil es seinen Zustand nicht ändern kann.

Allerdings hat das Value Object den Nachteil, dass man beim Ändern eines Attributs des Vertragsinhalts ein neues Objekt erzeugen muss, auch wenn die anderen Attribute unverändert bleiben. Dieser Umstand ist in der Praxis aber meist zu vernachlässigen.

Durch die Aufteilung lassen sich gegebenenfalls künftige Anforderungen leichter formulieren wie: "Das System soll es ermöglichen, einen neuen Vertrag auf Basis eines bestehenden Vertrags zu erzeugen. Dabei wird der Vertragsinhalt des Ursprungsvertrags übernommen." Realisieren lässt sich diese Anforderung durch einen Zweizeiler:

Kaufvertrag neuerVertrag = new
	   Kaufvertrag(ursprungsvertrag.getVertragsinhalt());

Da Value Objects unveränderbar sind und keine Identität haben, können sich beide Verträge eine Instanz des Vertragsinhalts teilen, ohne sich gegenseitig zu stören. Es sind keine Daten zu kopieren oder Objekte zu klonen. Durch geschicktes Ausnutzen dieses Umstands lässt sich der oben beschriebene Nachteil beim Ändern des Vertragsinhalts sogar mehr als kompensieren. Andererseits ließe sich dem neuen Vertrag auch eine neue Instanz von Vertragsinhalt zuweisen, die man mit den Ursprungsdaten initialisiert hatte. Für den logischen Programmablauf würde das wegen der Eigenschaften eines Value Object keinen Unterschied darstellen.

Die Unveränderbarkeit von "Vertragsinhalt" stellt außerdem sicher, dass das Objekt "Kaufvertrag" bei Änderung seines Vertragsinhalts informiert wird, weil in diesem Fall Kaufvertrag.setVertragsinhalt(...) aufzurufen ist.

Stefan Erras
ist selbstständiger Softwarearchitekt und -entwickler. Der Schwerpunkt seiner Arbeit liegt in der Erstellung geschäftskritischer Anwendungen.

Literatur (ane)

1. Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley 2003
2. AnemicDomainModel (Martin Fowler, 25. November 2003)