22. Mai 2013 | 2 min lesezeit

Mal etwas über Setter

Ich liebe die Konzepte von Clean Code und Domain Driven Design und deshalb möchte ich, dass mein Domänenmodell selbsterklärend ist. Und – ich hasse Setter!

Wer nicht weiß, worüber ich spreche, der sollte die JavaBeans Spec lesen, vor allem Kapitel 7.1. Setter sind fast immer falsch! Zumindest die, die automatisch von der IDE erstellt wurden. Entwickler, die Setter automatisch generieren lassen, setzen sich fast nie mit Fachlichkeit auseinander.

Ein Beispiel gefällig? Stellt euch eine Domain Model Entity vor, die eine Person darstellt. Eine einfache Personenentität könnte z.B. zwei Attribute haben: firstName und lastName. Ich kann mir keinen Use Case vorstellen, bei dem es sinnvoll ist, eine einfache Person ohne dieses Attributset zu erstellen. Und außerdem werden sich diese Attribute nicht so schnell ändern. Warum also sollte diese Person einen Constructor haben, der diese Attribute nicht zwangsweise setzt? Und warum sollte die Person Setter für diese Attribute haben?

„Moment mal“, wird der aufmerksame Leser hier rufen. „Was ist, wenn die Person heiratet?“ OK, das ist tatsächlich ein Use Case. Müssen wir den Use Case berücksichtigen? Falls ja, sollten wir diese Fachlichkeit implementieren. Aber ist das ein Grund setLastName(…), zu implementieren? Nein! setLastName(…)drückt in keinem Fall die Tatsache aus, dass es zu dem Use Case Hochzeit gehört. Und wenn wir den Use Case Hochzeit berücksichtigen müssen, müssen wir sicher auch wissen, ob eine Person verheiratet ist. Also brauchen wir mindestens ein drittes Attribut boolean married innerhalb der Personenentität und außerdem müssen wir es bei einer Hochzeit setzen. Also implementieren wir setMarried(boolean)?

Das meinte ich, als ich schrieb: „Entwickler, die Setter generieren lassen, interessieren sich fast nie für Fachlichkeit.“ Wir haben hier den Use Case Hochzeit und wir müssen zwei Attribute verändern. Es gibt keinen Grund, diese Attribute unabhängig voneinander zu setzen. Also sollten wir eine Methode implementieren, die diese Aufgabe exakt erledigt und auch ausdrückt, dass sie diese Aufgabe erledigt.

Wer diesen Code liest, erkennt sofort den Zweck der Methode und den zugehörigen Use Case. Für die Methode setLastName gilt das nicht. Also noch einmal: Man braucht keinen Setter!

Ok, normalerweise greift an diesem Punkt ein technisches Argument: Wenn ich diese Person in JSF erstellen möchte, brauche ich einen Default Constructor, um eine leere Person zu erstellen und ich muss Setter haben, um die Person zu füllen. Meine Antwort darauf (verweisend auf Matthäus 22,21) heißt: Gib JSF, was zu JSF gehört und gib deinem Domänenmodell, was zu dem Domänenmodell gehört. Ich möchte mein Domänenmodell nicht verschmutzen, nur weil eine Spezifikation wie JSF an einem 16 Jahre alten Standard festhält (man sehe sich nur mal das Veröffentlichungsdatum von JavaBeans an).

Also seid glücklich und erstellt eine JavaBean mit Gettern und Settern für JSF mit einer Action Methode, die eine Personentität erstellt, die sicherstellt, dass sowohl Vor- als auch Nachname korrekt ausgefüllt werden.

Schön ist das nicht und es ist ein Mehraufwand, der sich anfühlt wie ein Workaround für die Inkompetenz des Frameworks. In einem meiner nächsten Blogposts werde ich zeigen, wie man das Erzeugen von Objekten in JSF ohne Setter hinkriegt. Stay tuned.


Keine Kommentare

Kontakt

OPEN KNOWLEDGE GmbH

Standort Oldenburg:
Poststraße 1, 26122 Oldenburg

Standort Essen:
II. Hagen 7, 45127 Essen