5 Objektorientiertes Design

84 3 Objektorientiertes Design
Um sicherzustellen, dass wirklich nur Rasterpunkte erreicht werden können, wird durch
Aufruf der Methode snapToGrid(int) eine Modulo-Korrektur vorgenommen.
In der Klasse GridPosition werden jedoch zwei öffentliche set()-Methoden
angeboten, in denen keine Korrektur der Eingabewerte stattfindet. Rufen andere Klassen
diese set()-Methoden statt der Business-Methoden auf, so können beliebige Werte für
die Attribute x und y gesetzt werden. Diese liegen höchstwahrscheinlich nicht auf dem
gewünschten Raster und stellen somit auch keinen gültigen Objektzustand dar.
Tipp: Probleme durch öffentliche set()-Methoden
Häufig findet man in der Praxis eine Vielzahl öffentlicher set()-Methoden, über
die der Objektzustand auf unkontrollierte Weise geändert wird. Dadurch kann ein
gültiger Objektzustand nicht mehr gewährleistet werden.
Daher sollten set()-Methoden in ihrer Sichtbarkeit eingeschränkt oder – wie in diesem
Beispiel leicht möglich – komplett entfernt werden. Zuvor kann die Funktionalität
durch Business-Methoden bereitgestellt werden. Eine Anleitung dazu liefert das
Refactoring ERSETZE MUTATOR- DURCH BUSINESS-METHODE in Abschnitt 13.2.4.
In dieser Klasse wurden bereits Business-Methoden bereitgestellt, die set()-
Methoden jedoch nicht entfernt.
Weitere Komplexitäten durch Multithreading
Methodenaufrufe werden im Bytecode nicht als Ganzes abgearbeitet, sondern in Form
vieler kleiner Zwischenschritte. Dadurch kommt es immer zu Zwischenzuständen im
Objektzustand. Abbildung 3-12 zeigt dies für den Aufruf addOffset(50, 30).
Abbildung 3-12 Objektzustandsübergänge