Get/Set

RHBaum

@Shade

Lies doch bitte einfach den Artikel.

Dachte das hatt ich schon ...

getter und setter sollen überlegt eingesetzt werden! Denn viele Leute verwenden für jede member variable auch gleich getter und setter.

Was meinst du genau damit ? genau das versteh ich ja ned ... zumindest die disskussion drueber.

Ich mach alle members private/protected . Ist das Ok ?
Fuer alle variablen, die ich von aussen aendern muss/kann darf schreib ich setter ! Falsch ?
Fur alle variablen, die ich von aussen lesen muss, schreib ich getter. Falsch ?
Und wenn eine einzelne andere Klasse viel mit den internas meiner eigenen klasse zu tun hat (Iteratoren z.B), und auch speziell auf die verwaltung meiner klasse ausgelegt ist, dann mach ich die andere Klasse zum "friend" und vermeide so paar zusaetzliche getter und setter ...

Ciao ...

RHBaum

@Bashar Jo stimmt
Dann sind aber die MFC Progger bei MS keine VB Fans ! :p die z.B. lieben Get und Set ueber alles

Und ueber intuitive Namensvergabe laesst sich echt streiten ....

Beispiel ...
GetCount() ... Aehm welcher Container unterstuetzt SetCount(x) ???
size() ... Naja, schon besser ... aber warum Size und ned count ??? ... will ich anzahl oder groesse (ind was ) ? Als STL Newbie hatt ich echt probleme mit zu begreifen, das size() die aktuelle Anzahl der elemente und ned die momentan allocierte Groesse eines Containers ist .
Ich haett count() genommen ...

Ciao ...

Helium

Man hätte auch length verwenden können, wie einige andere Sprachen oder elements ... .

Fuer alle variablen, die ich von aussen aendern muss/kann darf schreib ich setter ! Falsch ?

Klar erkannt. Falsch! Wenn du sie ändern musst, ok, aber wie oft kommt es vor, dass du direkt ein Attribut ändern musst. Wenn du Sie ändern kannst? Das kannst du immer. Schwachsinn. Darf? Du darfst es, sobald es eine Methode gibt, mit der du es machen kannst.

finix

kingruedi schrieb:

Ich benutze die 2. Methode und finde nicht, dass diese verwirrt. Man wird ja als Programmierer schon den Unterschied zwischen
foo.kraft(1); //und
std::cout << foo.kraft() << std::endl;
erkennen. Wozu ich da extra get oder set vorschreiben sollte ist mir schleierhaft.

Was machst du wenn foo's kraft von etwas abhängig ist? Etwas was du erst übergeben musst?

Cocaine

Ist es denn dann noch eine Getter-Methode? Ich würd's dann eher calcForce() o.ä. nennen...

nman

finix schrieb:

Was machst du wenn foo's kraft von etwas abhängig ist? Etwas was du erst übergeben musst?

Was meinst Du?

Inwiefern sollte sich diese Methode dann von setKraft() oä unterscheiden?

finix

Cocaine schrieb:

Ich würd's dann eher calcForce()

Hm. Stimmt eigentlich. Aber trotzdem. Wenn du irgendwie mehrere Kräfte oder sonstwas hast und die über nen Index abfragen möchtest wirds auch kritisch.

nman schrieb:

Inwiefern sollte sich diese Methode dann von setKraft() oä unterscheiden?

Es ging um die Methode ohne Prefix.

junix

Helium schrieb:

Fuer alle variablen, die ich von aussen aendern muss/kann darf schreib ich setter ! Falsch ?

Klar erkannt. Falsch! Wenn du sie ändern musst, ok, aber wie oft kommt es vor, dass du direkt ein Attribut ändern musst. Wenn du Sie ändern kannst? Das kannst du immer. Schwachsinn. Darf? Du darfst es, sobald es eine Methode gibt, mit der du es machen kannst.

Äh hallo? irgendwie wird mir der Standpunkt hier nicht ganz klar. Ich bin absoluter Verfechter von Zugriffsmethoden. Und zwar konsequent auch für Attribute die nur klassenintern verwendet werden. Ich würde Shades Aussage eher umkehren: Das nicht verwenden von Set/Get-Methoden sollte mit Bedacht gewählt werden.

Wieso? Ganz einfach: Nur Get/Set Methoden garantieren mir, dass ich die Klasseninterna jederzeit beliebig umkrempeln und ergänzen kann, wies grad spass macht, ohne die ganzen Zugriffe auf das Objekt umbauen zu müssen.

Beispiel:
Ich habe ein Doc/View System mit den Klassen TmyDocument und TmyView. Beide gehören in einen Texteditor, wobei TmyView zur Anzeige des Textes in TmyDocument dient. TmyDocument stellt den Text in der Variable "MyText" zur Verfügung.

Nun wünscht man sich noch eine Möglichkeit definierte Revisionen zu erstellen. Um die Einfachheit der Bedieung sicherzustellen soll die Revisionskontrolle über ein weiteres Panel ermöglicht werden und an TmyView so wenig wie möglich rumgebaut werden.
Wo realisiert man nun sinnvoller Weise einen Revisionsspeicher? Innerhalb des Dokuments würde ich mal behaupten.

Wenn ich hier nun allerdings durch (fadenscheinige) Performance-Gründe die get-Methode (ebenso wie die Set-methode) spare, ist es mir nicht möglich, den Klasseninternen Speicher so umzubauen, dass ich zu guter Letzt nicht mind. 1 mal den Text doppelt im Speicher habe, weil ich ja die Revisionskontrolle habe, welche unter Umständen den zu speichernden Text speisen muss. Das erweiterte Interface? Kein Problem... was zum echten Problem wird ist der Zugriff auf MyText.... da kann ich nur um myText rumbauen und die Effizienz sinkt in den Keller. Wäre hier eine getter-Methode verwendet worden, hätte man ganz einfach die Methode so passend umgebaut, dass sie immer den gewünschten Revisionsstand zurückliefert.

... zugegeben ein konstruiertes Beispiel...vielleicht ist das Beispiel hier etwas naheliegender und entsprechend nachvollziehbarer:

Ich bau ne Anwendung mit ner Klasse XY welche ebenfalls irgendwelche Daten enthält welche sie für Berechnungen benötigt. Zunächst wird die Anwendung single-Threaded betrieben... Keine Synchronisationsprobleme, nix... Hauptsache Power.... also weg mit den 2-3 Takten die jeder Aufruf der Zugriffsmethode benötigt.
Nu kommts aber, dass eine weitere Anwendung gebaut wird, welche eigentlich auf die selbe Klasse zurückgreifen könnte, da sie die selben/ähnliche daten zu verarbeiten hat... diese Anwendung läuft allerdings blöderweise multithreaded... ...egal wird schon gehen.... nach tagelanger Problemsuche von sporadisch auftretenden Fehlern stehts fest: Synchronisationsprobleme.... tja.. was steht an? Umbau der zugreifbaren Variablen auf Zugriffsfunktionen welche CriticalSections verwenden... zack und schon muss ich meine 2. Anwendung - und natürlich auch die Erste um die Kompatibilität sicher zu stellen - umbauen.
Na dann danke.

Weitere Beispiele gefällig?

Ich hab noch ein paar auf Lager für all die, welche auf die Idee kommen "Set/Get-Funktionen brauchts ned" oder "sollten mit vorsicht eingesetzt werden". Was allerdings den Kern des Threads (wie man die Get/Set-Funktionen nun implementiert) angeht, muss ich sagen, dass ich alleine schon aus Gründen der Ordnung immer get/set voranstelle... Kostet mich ja nix und schafft eindeutige Verhältnisse.

So, und jetzt geh ich mal Asbestunterwäsche kaufen...

-junix

Asbest als atembare Fasern ist krebserregend.

Ich bin absoluter Verfechter von Zugriffsmethoden. Und zwar konsequent auch für Attribute die nur klassenintern verwendet werden.

warum aber zugriffsmethoden für attribute die nur klassenintern verwendet werden??????

das macht es keinen sinn,
es widerspricht dem kapselungsgedanken und verletzt ihn,
wenn es klassenintern ist warum soll dann bloss jemand von aussen überhaupt die möglichkeit haben etwas damit zu machen?,
es ist auch ein unnötiger und zusätzlicher aufwand

Wieso? Ganz einfach: Nur Get/Set Methoden garantieren mir, dass ich die Klasseninterna jederzeit beliebig umkrempeln und ergänzen kann, wies grad spass macht, ohne die ganzen Zugriffe auf das Objekt umbauen zu müssen.

wenn es für klasseninterna keine get/set methoden gibt, kann man sie noch viel besser umbauen und muss keine eigentlich sinnlosen methoden ändern

ich frage mich wieso überhaupt klasseninterna extern benutzbar sein sollten,
interna sind intern oder nicht?

extern sollten doch eher die möglichen aktionen sein

irgendwie kommen mir die klassen mit den ganzen get/set methoden mehr wie datenspeicher statt auf die problemlösung bezogene objekte vor,
es muss auch diese datenobjekte geben aber mit den get/set methoden wird jede klasse dazu

nman

finix schrieb:

Es ging um die Methode ohne Prefix.

Hilf mir auf die Sprünge, ich hab keine Ahnung was Du meinst.

finix schrieb:

Was machst du wenn foo's kraft von etwas abhängig ist? Etwas was du erst übergeben musst?

Was ist dann der Unterschied zwischen einem überladenen kraft() und setKraft()?

Jetzt wird aber ganz freakig. Ich bin generell gegen jegliche Verwendung von Klassen und auch gegen das schreiben von Funktionen außer der main-Funktion. Alle Variablen sollten direkt zu beginn definiert werden. So hab ich jederzeit follen zugriff auf alles. Und kann alles in jeder Situation genau so anpassen, wie ich es gerne hätte. Das nenne ich den Perfekten Programmierstil.

Walli

Jo, 1968 wars das auch.

Vellas

helium logged out schrieb:

Jetzt wird aber ganz freakig. Ich bin generell gegen jegliche Verwendung von Klassen und auch gegen das schreiben von Funktionen außer der main-Funktion. Alle Variablen sollten direkt zu beginn definiert werden. So hab ich jederzeit follen zugriff auf alles. Und kann alles in jeder Situation genau so anpassen, wie ich es gerne hätte. Das nenne ich den Perfekten Programmierstil.

*löl*
Klar und viel Platz sparen, also so viel in eine Zeile wie geht....

Code-Hacker

rüdiger

don't feed the trolls

DrGreenthumb

junix, niemand will get/set-Funktionen abschaffen und die Variablen public machen

Ging darum, dass viele get/set-Funktionen nicht viel besser als public-Variablen sind.
Beispiel: Statt player.setX(player.getX() + 10); sollte es lieber player.move() heißen, möglicherweise ein player, ganz ohne setX()-Funktion.

Aber irgendwie hat sich der Thread gewendet, ich glaube der Originalposter wollte nur wissen welche Namensgebung schöner ist.

Bashar

Ich verwende attr() und set_attr().

junix

bozo schrieb:

Ich bin absoluter Verfechter von Zugriffsmethoden. Und zwar konsequent auch für Attribute die nur klassenintern verwendet werden.

warum aber zugriffsmethoden für attribute die nur klassenintern verwendet werden??????

... Stichwort Ableitung/Vererbung ...

bozo schrieb:

es widerspricht dem kapselungsgedanken und verletzt ihn,

Den erkläre mir mal?

bozo schrieb:

Wieso? Ganz einfach: Nur Get/Set Methoden garantieren mir, dass ich die Klasseninterna jederzeit beliebig umkrempeln und ergänzen kann, wies grad spass macht, ohne die ganzen Zugriffe auf das Objekt umbauen zu müssen.

wenn es für klasseninterna keine get/set methoden gibt, kann man sie noch viel besser umbauen und muss keine eigentlich sinnlosen methoden ändern

? Äh ich weiss ja ned... aber wir sprechen hier nicht von einem wegschmeissen der alten Funktionalität welches nach aussen direkt Sichtbar wird...

In Anebtracht deines obigen Irrtums, erspare ich uns allen den Kommentar deiner weiterer Aussagen...

-junix

junix

DrGreenthumb schrieb:

junix, niemand will get/set-Funktionen abschaffen und die Variablen public machen

Da sah Shades Post allerdings etwas anders aus... hmmm

-junix

junix schrieb:

bozo schrieb:

warum aber zugriffsmethoden für attribute die nur klassenintern verwendet werden??????

... Stichwort Ableitung/Vererbung ...

Was hat das mit Vererbung zu tun? Btw, es gibt ja auch noch protected. Warum gleich public/getter/setter?

junix schrieb:

bozo schrieb:

es widerspricht dem kapselungsgedanken und verletzt ihn,

Den erkläre mir mal?

Was gibt es da bitte zu erklären? bozo hat völlig recht. Variablen, die du nur Klassenintern verwendest, gehen keinem was an.