getter und setter
Ich weiß nicht, ob hier jeder was damit anfangen kann, aber unter http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=2 gibt es einen Artikel, der mir immer wieder beim googlen unterkommt, wenn es um OO orientierte Programmierung geht. In dem Artikel wird die Meinung vertreten, daß getter und setter Methoden überflüssig und schädlich für die Refaktorisierbarkeit sind. Der Artikel ist von 2003, insofern kann es sein, daß die IDEs damals noch nicht so weit waren, aber selbst wenn, bin ich entweder total verblödet oder das ist der größte Schwachsinn, den ich je gelsen habe und das erscheint auch noch auf der großen Javaworld Seite.
Unter anderem wird so argumentiert:
A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details.
Wieso zeige ich Implementierungsdetails auf, wenn ich eine getSize() Methode habe? Von aussen sieht man nicht, wie “Size” berechent wird. Und auch die Kombination von mehereren get-Methoden wird darüber nicht Aufschluss geben. Wenn jetzt die Implementierung des Zusammenwirkens der Klassen untereinander gemeint ist, verstehe ich das schon eher, aber dann kommen wir schon zum nächsten Argument:
To see why, consider that there might be 1,000 calls to a
getX()method in your program, and each call assumes that the return value is of a particular type. You might storegetX()’s return value in a local variable, for example, and that variable type must match the return-value type. If you need to change the way the object is implemented in such a way that the type of X changes, you’re in deep trouble.
Natürlich ist man in “deep trouble”, aber nur, wenn man eine IDE hat, die das nicht automatisch refaktorisiert. In diesem “trouble” ist man aber auch, wenn man die getX() Methode weglässt. Und zuguterletzt ist das Problem beim direkten Zugriff auf public Member, daß nachträgliche Änderung der Datenverarbeitung der Membervariablen einen immensen Refaktorisierungsaufwand bedeuteten. Wenn zum Beispiel getX() plötzlich nicht mehr einfach x zurückgibt, sondern vielleicht x+1, dann wünsch ich viel Spaß beim Ändern der ganzen Codestellen, an denen direkt auf x zugegriffen wird.
Irgendwie steig ich nicht dahinter, was das für eine skurrile Theorie sein soll und vor allem sind alle Kommentatoren derselben Meinung. Seltsam…
