Get-/Set-Methoden: Wann sinnvoll?



  • Hi,

    manchmal frage ich mich, wann Get-/Set-Methoden sinnvoll sind und wann nicht. Immer Get-/Set-Methoden zu benutzen ist sehr sauber und garantiert volle Kontrolle über die Daten durch die Klasse. Allerdings brauchen sie mehr Ressourcen und sind umständlicher zu benutzen. Die Variablen in den public-Teil zu schreiben hat aber auch den Vorteil, dass man direkt, ressourcenschonend und einfach auf sie zugreifen kann. Wie sollte ich vorgehen?

    LG Raz



  • Was heißt da "resourcenschonend"? Wie immer gilt natürlich die Abwägung: Sicherheit gegen Schnelligkeit. Wobei das IMHO hier keine allzu schwere Entscheidung ist.
    Das schöne an Get/Set-Methoden ist, dass du Vorbedingungen etc. sicherstellen kannst, im Notfall Zugriffe loggen und solche Späße. Und das ganze bei minimalen Kosten, wenn es Einzeiler sind wird es eh geinlined und dann sollte sich der Methodenaufruf endgültig nicht mehr von der rohen Zuweisung unterscheiden (der, außer bei PODs auch auf den Aufruf eines operator=() hinausläuft, also auch nicht direkt kostenlos ist).



  • Razoron schrieb:

    ...Die Variablen in den public-Teil zu schreiben...

    Das widerspricht dem Paradigma der objektorientierten Programmierung.

    Verzichte weitestgehend auf get-/set-Methoden, und implementiere sie nur dann, wenn du sie wirklich brauchst. get und set müssen auch nicht immer Hand in Hand gehen. Wenn du nur die set-Methode brauchst, dann lass die get-Methode weg.

    lg



  • Also ich mache meine Klassenmember so gut wie immer privat, außer man soll von außen einfach drauf zu greifen können, was aber eg bei mir nie der Fall ist.
    Und wenn ich dann eben Get- und oder Set-Methoden brauche, dann implementiere ich sie und ansonsten nicht 😉

    Lg freeG



  • Razoron schrieb:

    Immer Get-/Set-Methoden zu benutzen ist sehr sauber

    Stimmt nicht. Zuviele Getter und Setter sind oft ein Hinweis auf schlechtes Design (gerade wenn für jedes Attribut 1:1 Get-/Set-Methoden existieren).

    Razoron schrieb:

    Allerdings brauchen sie mehr Ressourcen

    Nein, heutige Compiler sind da sehr gut. Und selbst Overhead ist hier meist vernachlässigbar. Die Entscheidung zwischen Set-/Get-Methode und einer Alternative ist fast nie eine Performancefrage.

    Du musst vom Gedanken wegkommen, dass jede Eigenschaft der Klasse je einen Getter und einen Setter erfordert. Oft ist es sinnvoller, "High-Level-Funktionen" anzubieten (z.B. Player::TakeDamage() statt Player::SetHitpoints() ). Manchmal reicht auch nur entweder Get oder Set.



  • Nexus schrieb:

    Razoron schrieb:

    Allerdings brauchen sie mehr Ressourcen

    Nein, heutige Compiler sind da sehr gut. Und selbst Overhead ist hier meist vernachlässigbar.

    Bei einfachen Getter/Settern wird kein aktueller Compiler anderen Code erzeugen, als wenn die Attribute public wären. Und falls man wirklich keinen trivialen Getter/Setter hat braucht man sowieso irgendeine Funktion, wenn man nicht ständig überall die gleichen Abfragen wiederholen will. Aber auch da wird ein aktueller Compiler sogar den selben Code erzeugen.
    Ressourcen/Performance ist da also eigentlich nie eine Frage.



  • Danke für eure Einschätzungen/Tipps! Gut, dann vertrau ich mal darauf, dass er Compiler guten Code erzeugt. Jetzt nochmal ein Beispiel: Ich habe eine Klasse material, die mehrere Daten bezüglich des Shadings beinhaltet. Dabei gibt es viele Einstellungen, die dazu da sind, dass der Benutzer sie ändert und anpasst.
    Z.B. diese:

    vec3f emmission;
            vec3f ambient;
            vec3f diffuse;
            vec3f specular;
            float shine;
    

    Jetzt erhöhe ich den ambient-Wert:

    // Get-/Set-Methoden
            vec3f amb = ent1->get_ambient();
            amb += 0.01;
            ent1->set_ambient(amb);
    
            // Public
            ent1->ambient += 0.01;
    

    Meine vec-Klasse ist mit allen möglichen Operatoren ausgestattet. Man sieht, dass der Zugriff besonders einfach ist, wenn man die Variablen im public-Teil vereinbart. Welche Möglichkeit macht hier, bei diesem "extremen" Beispiel am meisten Sinn? Selbst um Get-/Set-Methoden kommt man ja nicht rum.


  • Mod

    In solchen Fällen, wo man einfach eine Datensammlung ohne echte Funktionalität hat (außer das die Daten gesetzt und abgefragt werden können), lasse ich alles public.



  • Dann überleg ichs mir nochmal, danke :).



  • SeppJ schrieb:

    In solchen Fällen, wo man einfach eine Datensammlung ohne echte Funktionalität hat (außer das die Daten gesetzt und abgefragt werden können), lasse ich alles public.

    Auch wenn ich den Grund verstehe, und es auch häufig genug genau so mache, habe ich durchaus ein Argument auch hier für Getter/Setter - zumindest wenn die IDE kein Refactoring unterstützt (und beruflich arbeite ich leider mit solchen):

    Wenn man nachträglich doch noch Logik hinzufügt (und sei es nur Bereichsprüfungen etc.), muss man, wenn man keine Getter/Setter verwendet, alle Stellen suchen und ändern (Ein Grund weshalb ich persönlich Properties wie in C# mag, wo man dies ohne Syntaktische Änderungen nachpflegen kann).



  • asc schrieb:

    Wenn man nachträglich doch noch Logik hinzufügt (und sei es nur Bereichsprüfungen etc.), muss man, wenn man keine Getter/Setter verwendet, alle Stellen suchen und ändern (Ein Grund weshalb ich persönlich Properties wie in C# mag, wo man dies ohne Syntaktische Änderungen nachpflegen kann).

    In Reine "Datensammelklassen" sollte man IMO nie irgendwelche Logik einfügen.
    Bereichsprüfungen etc. gehören in die Funktionen die diese Daten dann übergeben bekommen.


Log in to reply