Getter-Methoden

[QXARE]

Hallo,

ich wollte mich mal umhören, ob Getter-Methoden ausschließlich in fremden Klassen bzw. von außen zu verwenden sind, oder ob man sie auch für den Zugriff auf die eigenen Klassenvariablen verwendet?

Gibts da irgendwelche Nachteile wenn man innerhalb der Klasse über die Getter Methode auf die jeweilige Variable zugreift - und nicht direkt?

 

[Green Mamba]

Einen Nachteil hats, du hast einen Function-Call mehr pro Aufruf.
Vorteile gibts da imho keine.

 

[kinglouy]

Nen Vorteil gibts auch. Es kann sein, dass irgendwelche Operationen bei jedem Zugriff auf bestimmte Datenfelder ausführt werden sollen. Sowas geht natürlich nur, wenn es entsprechende Getter-Methoden gibt. In solchen Fällen bietet es sich an auch intern die Getter zu benutzen.
Wenn in der Methode allerdings nur nen Return-Statement steht, ist es fragwürdig. Hängt auch ganz von dem Datenfeld bzw. von der Klasse ab. Wenn es unwahrscheinlich ist, dass sich die Struktur nochmal stark verändert (z.b. bei einer Vektorklasse, Vektoren sind nunmal fest definiert), dann kannst du wohl darauf verzichten, intern auch Getter-Methoden zu verwenden.

Getter-Methoden sind ja kein Allheilmittel, sondern ein Lösungsansatz für Probleme, die mit späteren Änderungen des Codes einhergehen. Durch die Getter-Methoden müssen in vielen Fällen nur Änderungen in der entsprechenden Klasse gemacht werden, während ein direkter Zugriff aufs Datenfeld auch Änderungen in anderen Klassen zur Folge haben kann.

Sogesehen ist es in den Fällen, in denen die Struktur einer Klasse feststeht (z.b. wieder Vektoren), auch denkbar, die Datenfelder öffentlich zugänglich zu machen, um sich den Methodenaufruf zu sparen. SO genau brauchst du allerdings in den meisten Anwendungen nicht auf die Performance zu achten und solltest lieber den Weg des besseren Designs wählen.

 

[kuddlmuddl]

Je nach Entwicklungsumgebung kanns halt Probleme geben, wenn man sich vertippt.
Beispiel:

if (this._member1 = 100) {
    // do sth
}

Da gibts jetzt ne Zuweisung und evtl keine Warnung.
Hätte man stattdessen mit ner getter Methode gearbeitet ist so ein Fehler ausgeschlossen, da es schon beim Compilieren fehlschlagen sollte

if (this.getMember1() = 100) {
    // do sth
}

 

[Stefan_Sch]

Getter-Methoden sind ja kein Allheilmittel, sondern ein Lösungsansatz für Probleme, die mit späteren Änderungen des Codes einhergehen. Durch die Getter-Methoden müssen in vielen Fällen nur Änderungen in der entsprechenden Klasse gemacht werden, während ein direkter Zugriff aufs Datenfeld auch Änderungen in anderen Klassen zur Folge haben kann.

Member sind für äußere Klassen selten relevant und darum geht es. Wieso sollte eine Klasse, die intern einen kryptographischen Algorithmus berechnet alle seine Member öffentlich machen? Das wäre Irrsinn und man würde gegen den OO Ansatz verstoßen, nämlich das ein Objekt seine Implementierungsdetails verbergen sollte.

Getter/Setter sollte man deshalb möglichst vermeiden bzw. gering halten. Bei Datenklassen ist das natürlich nicht möglich, aber die sind die Ausnahme.

Ob man intern Getter/Setter benutzt ist eine Frage des persönlichen Geschmacks. Derjenige, der die Klasse geschrieben hat, kann darüber selbst entscheiden, weil er derjenige ist, der die Interna der Klasse kennt. Bei "intelligenten" Gettern/Settern, kann es hilfreich sein diese in der Klasse aufzurufen um beispielsweise eine Codeduplizierung zu vermeiden.

 

[kinglouy]

Member sind für äußere Klassen selten relevant und darum geht es. Wieso sollte eine Klasse, die intern einen kryptographischen Algorithmus berechnet alle seine Member öffentlich machen? Das wäre Irrsinn und man würde gegen den OO Ansatz verstoßen, nämlich das ein Objekt seine Implementierungsdetails verbergen sollte.

1. Ich sagte nicht, dass es zwingend für jedes Datenfeld einen Getter/Setter geben muss oder ob es überhaupt Getter/Setter geben sollte. In dem Thread geht es aber darum, dass es schon welche gibt und ob man sie intern verwenden sollte. Es ist logisch, dass es Daten gibt, die vollständig im Verborgenen bleiben sollen.

2. Ich sagte, dass es denkbar ist bei Klassen, deren Struktur absolut feststeht und sich aufgrund der Definition dessen, was die Klasse repräsentiert, nicht ändert. Ich sagte zwar nicht explizit, dass das nur für Datenklassen zutreffen soll, aber das Beispiel "Vektor" sagt das eigentlich schon. Dein kryptografischer Algorithmus passt so überhaupt nicht zu dem, was ich zu öffentlichen Datenfeldern sagte.

3. Es ist durchaus üblich in manchen Bereichen keine Getter/Setter zu verwenden, sondern einen öffentlichen Zugriff auf Datenfelder. Sowas wird allerdings nur in Anwendungen gemacht, die die beste Performance bieten sollen (Echtzeit) und auch nur für die sogenannten Datenklassen bzw. Structs in C++/C#. Als Beispiel fallen mir z.B. die Vektoren des XNA Frameworks ein (die Klassen Vector2, Vector3 und Vector4).

 

[Rossibaer]

Wenn eine Klasse/Struktur als reiner Datencontainer ohne jegliche Programmlogik herhalten soll, dann würde ich wahrscheinlich ausschließlich Felder öffentlich verfügbar machen wollen. Sobald aber auch nur eine Funktion hinzukommt, würde ich sofort auf Getter/Setter wechseln um hier konsistenten Zugriff sowohl innerhalb als auch außerhalb zu gewährleisten. Innerhalb Getter und Setter wird dann die Validierung der eingehenden/ausgehenden Daten übernommen, sodaß ich das nicht in jeder Funktion dann immer wieder neu schreiben/kopieren muss.

Getter/Setter werden wahrscheinlich etwas langsamer, aber auch bei größeren Projekten habe ich noch keinen wirklich für mich spürbaren Verlust entdeckt. Das liegt aber auch daran, dass der eigentliche Flaschenhals in meinen Applikationen/Projekten mehr bei I/O über Netzwerk zu Fileserver/Datanbankserver liegt und somit der Verlust durch Getter/Setter nicht wirklich relevant erscheint.

Bei anderen Anwendungstypen, die weniger mit der "Außenwelt" kommunizieren und hier letztenendes die reine Prozessorleistung entscheidet, wirds natürlich schon eine Rolle spielen und sollte auch sehr kritisch betrachtet werden, da wie Green Mamba schon schrieb, jeweils ein Funktionsaufruf mit all dem "Overhead" der beim Wechsel in eine andere Funktion entsteht, notwendig wird. Das wird man als Programmierer selber nicht unbedingt vor den Augen haben. Jedoch wird es die Geschwindigkeit beeinflußen. Beispiele wären für mich dann wohl Packprogramme, Bild-/Videobearbeitung, Spiele etc.

Am Ende bleibts aber der eigene persönliche Geschmack des Einzelnen, ob und wie er innerhalb seines Programmierstils Getter und Setter einsetzt. Der eine verwendet es mehr, der andere weniger...

 

[antred]

Getter/Setter werden wahrscheinlich etwas langsamer, aber auch bei größeren Projekten habe ich noch keinen wirklich für mich spürbaren Verlust entdeckt.

Mit den entsprechenden Optimierungsstufen wird der Compiler triviale Getter/Setter wahrscheinlich sowieso inlinen, weshalb der vermeintliche Geschwindigkeitsverlust eigentlich kaum von Belang ist.

 

[SheepShaver]

Wenn eine Klasse/Struktur als reiner Datencontainer ohne jegliche Programmlogik herhalten soll, dann würde ich wahrscheinlich ausschließlich Felder öffentlich verfügbar machen wollen.

Membervariablen sollten eigentlich nie public sein, auch wenn es sonst keine Logik in der Klasse gibt. Die Kapselung von internen Datenstrukturen ist ein grundlegender Bestandteil von OOP.

 

[Rossibaer]

SheepShaver: Voll am Ziel vorbei geschossen, oder?! Nen mir mal den Unterschied zwischen Struktur und Klasse. Frag 5 Informatiker was OOP ist und du wirst 6 Antworten bekommen. Wenn du jetzt noch nach den grundlegenden Bestandteilen von OOP fragst, kannst du auch genauso gut die Anzahl der Befragten zum Quadrat nehmen und erhälst damit die Anzahl der Antworten. Mal ganz ehrlich, lass die Kirche im Dorf. Bei einer Struktur/Klasse, die nichts macht außer ein paar Variablen zu beherbergen, ist eindeutig am Ziel vorbei geschossen, wenn dann auch noch Getter und Setter implementiert werden. Man kann es echt übertreiben. Wie sieht es mit Schnittstellen zu Fremdsystem aus, die einfach nur eine Struktur erwarten. Soll ich diese Systeme dann auch mit aller Macht auf OOP trimmen? Wird schwierig, wenn ich keinen Zugang zum Quellcode habe. Achja, ich vergaß, dass OOP die Lösung all unserer Probleme ist.

 

[SheepShaver]

Structs sind sowieso Bad Practice und ein C-Relikt und ja, man sollte imho immer über Getter und Setter zugreifen. Anders ist eine Zugriffskontrolle (essentiell bei der Fehlersuche) überhaupt nicht möglich. Die interne Struktur einer Klasse sollte nie nach außen hin sichtbar sein, bei inner classes meinetwegen, sonst niemals.

 

[Rossibaer]

Sorry sheepshaver, du verwendest mir zuviele Buzzwords um von meinen Fragen abzulenken. Sind das Nebelbomben um hier ein bißchen Verwirrung zu stiften? Mir wird jedenfalls schon schwindlich: Structs, Bad Practise, C-Relikt, Zugriffskontrolle, inner classes ...

Immerhin bist du auf keine einzige Frage eingegangen...

 

[hasugoon]

Anstatt ner Getter-Methode, die einfach nur den Variablen-Wert zurückgibt, würde ich Properties verwenden, sofern es die Sprache hergibt. Die kannst du dann auch in derselben Klasse verwenden. Getter würde ich nur von ausserhalb verwenden oder wenn sie halt etwas komplexer sind.

 

[antred]

Structs sind sowieso Bad Practice und ein C-Relikt und ja, man sollte imho immer über Getter und Setter zugreifen. Anders ist eine Zugriffskontrolle (essentiell bei der Fehlersuche) überhaupt nicht möglich. Die interne Struktur einer Klasse sollte nie nach außen hin sichtbar sein, bei inner classes meinetwegen, sonst niemals.

Google mal nach "POD struct C++". Bei einem stinknormalen struct, das nix weiter als ein paar Membervariablen und keinerlei interne Logik enthält, ist es vollkommen bescheuert, für jede Variable ein Getter/Setter-Paar zu implementieren. Und was an solchen structs "bad practice" sein soll, ist mir rätselhaft. OOP und data hiding / Kapselung ist ja 'ne wunderbare Sache, aber das heißt nicht, daß normale Datenstructs nirgend wo mehr benötigt werden.

 

[SheepShaver]

PODs und Get- und Set-Methoden stehen nicht im Gegensatz. Eine Klasse, die nur private Membervariablen besitzt und die korrespondierenden Getter und Setter ist immernoch ein POD. Von bescheuert kann also keine Rede sein. Es ist einfach eine konsequente Anwendung des OO-Paradigams.
Nicht umsonst hat Java überhaupt keine Structs und in C++ sind sie wie gesagt auch nur ein Relikt aus C-Zeiten.

 

[roker002]

Die Properties sind nichts anderes als Methoden, die einfach anders aussehen! Nach dem Compilieren sieht man, dass der Zugriff mit "get_DeinPropertyName" oder "set_DeinPropertyName" auf die Properties erfolgt. Naja zumindest sieht man es im StackTrace by eine Exception.

Ich denke es hängt immer vom Compiler wie schnell die Getter/Setter verarbeitet werden.

PS:
und ja, MS verwendet sehr oft die Structs.

 

[Rossibaer]

Ich vermute mal, dass der TE von C++ spricht, da ich in den restlichen mir bekannten Sprachen Properties statt Getter und Setter implementieren kann, aber seine Frage explizit nach Getter / Setter gerichtet ist.
Nehmen wir mal an, die Sprache wäre C++. Dann SheepShaver, erkläre mir bitte: Wo liegt der Unterschied zwischen einer Klasse und einem Struct?

 

[roker002]

ich glaube die Antworten findet man hier

Als C Programmierer ist man auf Structs sehr angewiesen da man keine Klassen hat. Bei OOP Sprachen wird Struct eher weniger wichtiger. Structs werden halt im Speicher anders behandelt.

Value type local instances are allocated on the stack. Reference type local instances are allocated on the heap.

 

[antred]

ich glaube die Antworten findet man hier

Als C Programmierer ist man auf Structs sehr angewiesen da man keine Klassen hat. Bei OOP Sprachen wird Struct eher weniger wichtiger. Structs werden halt im Speicher anders behandelt.

Nix wird im Speicher anders behandelt. struct und class ist genau das gleiche ... EINZIGER Unterschied: beim struct ist per default die Zugriffstufe public, während sie in einer class per default private ist. Ansonsten gibt es Null Unterschied zwischen class und struct.

 

[roker002]

@antred
hast du nicht gelesen? Value Type = Struct = im Stack gespeichert, Reference Type = Class = im Heap gespeichert! wo siehst du den kein unterschied?

hier noch ein Link zur Stack VS Heap. Einfach alles durchlesen!