Erste Schritte Verständnisfrage: Getter und Setter Methoden

[Thoosequa]

Hallo Leute!

Nach viel zu langer Zeit und stümperhaftem coding in der Bukkit API bin ich wieder auf den rechten Pfaden wandelnd zu "Java von Kopf bis Fuß zurückgekommen". Schon einige Kapitel weiter aber trotzdem noch ein Fragezeichen sind für mich Setter und Getter Methoden. Ich weiß zwar wie ich solceh Getter und Setter Methoden in meinen Code implementieren würde, mir fehlt aber aus irgendeinem Grund vollkommen das Hintergrundwissen warum ich meine Variablen durch Setter und Getter "schützen" soll.

Kann mir vielleicht jemand weiterhelfen und in einfachen Worten erklären was Getter und Setter sind und inwiefern sie für meinen Code wichtig sind?

Gruß, thoose

 

[troll]

das hat zwei hauptgründe

1) der scope sollte immer so klein wie möglich gehalten werden
2) getter und setter waren die konsistenz der datenstruktur ...
z.b. kann es wichtig sein das eine variable in abhängigkeit zu einer anderen mit geändert werden muss .. diese aufgabe wird im setter erledigt ...
wenn man die variable direkt ändern würde würde die andere unter umständen nicht mitgeändert werden was zu fehlern führen würde ...

das ganze nennt man auch datenkapselung ...
für ihre variablen sollte eine klasse immer nur selbst verantwortlich sein ... direkte äußerungen von außen (wie z.b. beim GridBagLayout) sollten vermieden werden ...

 

[vanny]

naja du hältst deine Variablen(Member) private, so dass nur die Klasse selbst direkt auf diese zugreifen kann.
Der Vorteil ist, dass du von aussen nur per Methode um einen Wert oder dessen Änderung bitten kannst und somit keine flaschen Handhabungen mit deinen Klassendaten möglich sind.
Diese nennt man halt Getter und Setter.

Beispiel.:
Du hast eine Klasse "PlanZiel", in der ein Datum "termin" als Membervariable existiert, die beschreibt, wann der Vorgang planmäßig beendet werden soll.
Dann kannst du mit einer setMethode prüfen, ob das Datum wirklich in der Zukunft liegt, denn nur das macht Sinn.
Wenn du das nicht machst und den direkten Zugriff von aussen erlaubst, kann es sein, das das nächste Planziel für Vorgestern geplant ist ^^

Gruß Vanny

 

[Ark]

Es gibt noch einen Grund, der bisher nicht genannt wurde: Du kannst mit solchen Methoden die Implementierung verstecken.

Beispiel: Du stellst fest, dass die 18 einzelne booleans in deinem Objekt zu viel Speicher belegen und willst deshalb die entsprechenden Werte auf die Bits dreier bytes abbilden. Wenn du mit Gettern den Zugriff auf die Felder regelst, kannst du diese Änderung gefahrlos durchführen: Die Aufrufer der Getter bekommen davon nichts mit, da die Getter nach wie vor booleans zurückgeben. Intern müssen die Getter natürlich dann etwas mehr rechnen, aber das, wie gesagt, sieht man dann von außerhalb nicht.

Würdest du an dieser Stelle stattdessen den direkten Zugriff auf die boolean-Felder erlauben, kann es passieren, dass alle anderen Klassen, die auf diese Felder zugreifen, plötzlich nicht mehr funktionieren, sobald du da was zu ändern versuchst. In dieser Situation hättest du grob nur noch zwei Möglichkeiten: Du lässt alles beim Alten (d.h., du kannst deinen Code nicht mehr optimieren) oder du ziehst deine Änderung doch durch (und alle anderen Klassen sind auf einmal kaputt). Beide Alternativen sind schlecht.

BTW: Ich habe so gut wie nie Setter in meinem Code, und nahezu alle Felder/Variablen/Klassen sind final. Das hilft wirklich sehr dabei, Code wartbar zu halten.

Es ist auch vollkommen (also gut, nicht ganz, aber fast vollkommen) nutzlos, Felder private zu machen, dann aber doch für alle Felder öffentliche Getter und Setter bereitzustellen, die alles ungefiltert akzeptieren.

Anstatt also bei Eclipse auf die automatische Generierung von Settern und Gettern zu setzen, nur um dann zu überlegen, wie man vor allem die Setter richtig "absichert", sollte man besser gleich davon absehen, überhaupt das Ändern von Feldern zuzulassen.

Ark