spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Eigentlich ist es ja jedem selbst überlassen, bzw geschmacksache, jedoch bin ich der meinung, das man beides nicht mischen sollte. einheitlichkeit ist da viel wichtiger. ich bin von g/s überzeugt, und werde sie auch weiter nutzen, allein schon weil ich darin nur vorteile sehe, und die 2 zeilen die ich eventuell mehr schreiben muss, stören mich nicht wirklich.

Zitat von »Schorsch«

Wollte kurz was dazu sagen, dass Getter/Setter gegen das Prinzip der Kapselung verstoßen sollen. Die Kapselung bleibt vorhanden,

Dann hast du den Sinn der Kapselung noch nicht richtig verstanden. Nur weil die Member nur über Umwegen zu erreichen ist, ist eine Klasse noch lang nicht richtig gekapselt.
Das Problem ist, dass Getter und Setter ermöglichen Dinge zu tun, die eigentlich in die Klasse gehören. Das führt zu Redundanz und die führt zu Problemen.

Wie fast überall kann man keine absolute Aussage machen. Getter und Setter sind manchmal nötig, sollten wenn möglich vermieden werden. Kann man garantieren, dass die Getter und Setter (bei guten Programmierern) nicht zu Redundanz sind sie kein Problem.

Mal ein ganz einfaches Beispiel:

anstatt:

besser:

Bei der ersten Variante mit Setter könnte man denken, dass da nichts weiter passiert als dass eine string-Variable auf "Hans" gesetzt wird. Das denkt man ganz intuitiv, weil es meistens nunmal so ist.
Es könnte aber sein, dass das Ändern des Namens ziemlich viel Arbeit ist, dann fände ich die zweite Variante besser. Sie lässt keine Vermutungen zu, was intern passiert (für mich ein gutes Indiz für Kapselung).

Gut über Benennungen lässt sich streiten. Sehe es aber nicht ein, dass Getter und Setter gegen das Prinzip der Kapselung sprechen. Wenn ein Getter bzw Setter einfach weiterleitet, ist das an sich richtig. Solange man aber von Methoden spricht, welche nicht das selbe tun wie public Member, kann von Kapselung gesprochen werden. Du verschleierst die Implementierung. Ich weiß selbst, dass viele über sowas schimpfen und behaupten das wäre nicht OOP, sehe das aber anders. Wie gesagt, was intern passiert wird verschleiert, ob der Wert nun berechnet, aus einer Datenbank geholt oder was auch immer wird. Man darf sich halt nicht verkrampfen und Getter/Setter als public Member Ersatz sehen.
Aber wie gesagt OOP Fragen sind meistens Streitthemen und deswegen klinke ich mich hier wieder aus. Werd mir nen Buch über OOP kaufen und lernen was es wirklich ist. Hab ja anscheinend kein besonders gutes Verständnis davon

ein Beispiel für die Notwendigkeit eines Setter:
ein Objekt soll eine (oder mehrere) Zeichenkette(n) (wie Beispielsweise Name/ID/Wert/Filter/...) enthalten
es wird davon ausgegangen, dass tatsächlich eine Zeichenkette vorhanden ist, auch wenn diese leer ist
somit wäre eine null-Referenz (/null-Pointer) ein ungültiger Wert
entweder verwendet man einen Getter, der entsprechend schaut, ob der Wert null oder eine Zeichenkette ist und ggf. eine leere Zeichenkette liefert
oder man verwendet einen Setter, der entsprechend entweder den Wert oder eine leere Zeichenkette zuweist

wenn die Membervariable öffentlich wäre, würde die Gefahr bestehen, direkt darauf zuzugreifen und den Wert falsch zu setzen
in dem Fall müsste ein Getter verwendet werden, allerdings besteht ebenfalls die Gefahr, dass direkt auf die Variable zugegriffen wird

wenn die Membervariable privat ist, dann ist es von außen gesehen egal, ob der Wert vorher oder nachher angepasst wird
es könnte bei der internen Implementierung aber zu Fehlern kommen, wenn der Getter die Prüfung übernimmt und man direkt auf die Variable zugreift


entsprechende Variablen habe ich auf Arbeit derzeit sehr viele

außerdem haben wir sehr viele Getter, die einen Wert liefern, der erst ermittelt wird (aus den gespeicherten Werten zusammengesetzt, abhängig von den gespeicherten Werten aus der Datenbank ausgelesen, ...)
allerdings gibt es in diesen Fällen keine entsprechenden Setter (abgesehen von den Settern für die Variablen, die das Ergebnis beeinflussen)
(mal abgesehen von den Fällen, in denen in einem Interface/einer abstrakten Klasse Getter definiert werden)


Schreibarbeit bei Settern:
Eclipse beispielsweise kann aus vorhandenen Membervariablen automatisch Getter und Setter generieren - Standardgetter und -setter erfordern also keinen großen Zeitaufwand


mal ganz davon abgesehen, dass die einen oder anderen Klassen, um als Beans verwendet werden zu können, zwingend Getter und Setter brauchen (zumindest für die Werte, die von außen benötigt werden)
(woraus auch resultiert, dass für das Hinzufügen eines Werts zu einer Liste ein Setter verwendet werden muss, siehe Expression Language bzw. Java Beans x.x)

Ich bin auch nicht aus Prinzip gegen Getter/Setter. Es ist halt nur falsch zu denken, nur weil die Variablen nicht mehr public sind, seien sie gekapselt. Dieses Eclipse Automatikfunktion find ich dann total abartig, weil man dazu animiert wird, alles "public" zu machen.
G/S aus Gründen der Einheitlichkeit für Variablen zu benutzen, die ansich public sind, ist natürlich auch ein Argument. Allerdings will man solche Werte, wenn man sie schon direkt modifizeiren kann vielleicht ein Abhängigkeit vom alten Wert ändern (+=5), was sich mit public Variablen einfach viel schöner und übersichtlicher schreibt.

Davids Punkt finde ich auch wichtig. Ich benutze Beispielsweise Namen wie CalculateBlub() um die Komplexität anzudeuten. Letztendlich kann man sich auch fragen, ob es überhaupt sinnvoll ist, das Interface so unabhängig von der Implementierung zu machen, dass man nicht einmal den Aufwand eines Aufrufes abschätzen kann. Eine Get-Methode die auf einmal Wert umständlich berechnet (Mittelwert oder ähnliches) statt einen zwischengespeicherten Wert zurückzuliefern ist doch nichts, was man wirklich benutzen will.

G/S ist etwas, das man jedesmal wieder überdenken muss. Manchmal braucht man sie, manchmal täuschen sie aber auch nur nicht vorhandene Vorteile vor.

Zitat von »Jonathan_Klein«

Davids Punkt finde ich auch wichtig. Ich benutze Beispielsweise Namen wie CalculateBlub() um die Komplexität anzudeuten. Letztendlich kann man sich auch fragen, ob es überhaupt sinnvoll ist, das Interface so unabhängig von der Implementierung zu machen, dass man nicht einmal den Aufwand eines Aufrufes abschätzen kann. Eine Get-Methode die auf einmal Wert umständlich berechnet (Mittelwert oder ähnliches) statt einen zwischengespeicherten Wert zurückzuliefern ist doch nichts, was man wirklich benutzen will.

Wenn die Daten selten verändert werden, aber der Mittelwert ständig abgerufen wird, dann wird man bei der Implementierung im Setter der Daten den Mittelwert gleich mit berechnen und speichern wollen.

Und der Mittelwert ist eigentlich eine super Beispiel für einen Getter. Wenn du den als öffentliche Variable anbietest könnte jemand den Wert verändern. Sinnlos, aber leider möglich.

^Getter und Setter sind wie oft genannt wurde dazu da um die Werte beim setzen einer Eigenschaft validieren zu können. So darf die Methode "Größe" einer Klasse "Mensch" nicht kleiner oder gleich 0cm sein, da so klein kein Mensch sein kann. Getter sind das gegenstück dazu. Es gibt auch Getter die bestimmte Eigenschaften miteinander verrechnen und das Ergebnis geben.

Das Argument, dass Getter/Setter gegen die Kapselung von Daten sei ist nicht richtig. Man bedenke, dass sich Klassen verändern und auch die Verarbeitung mit den Eigenschaften nicht immer gleich sind. Habe ich Setter/Getter auch für Eigenschaften die zurzeit nicht validiert werden (also Setter/Getter geben einfach nur die Eigenschaft durch) kann ich diese Methoden in späteren Versionen der Klasse abändern ohne das der Anwender etwas an seinem Code verändern muss.

Desweiteren sind Setter oft gut um Abhänigkeiten zu aktualisieren. Ändere ich die Größe eines Buttons kann der Setter die Zeichen-Methode aufrufen und den Button direkt neu zeichnen.

Getter und Setter gehören zum sauberen OOP Ansatz. Mehr braucht man dazu nicht sagen

Meine Erfahrung ist, dass Getter und Setter meistens Symptome von schlechtem OO Design sind. Und offenbar bin ich da nicht allein:

http://www.javaworld.com/javaworld/jw-09…05-toolbox.html
http://stackoverflow.com/a/565227
http://www.codeinstructions.com/2008/08/…s-are-evil.html
http://typicalprogrammer.com/?p=23
...