Get/Set

Vellas

Ich würde ebenfalls die erste Methode benutzen, da ich an der zweiten doch nicht wirklich erkennen kann was die eine macht und was die andere macht.

Helium schrieb:

Die Funktionsweise wird in jedem Fall verändert. Du kannst wohl kaum überladen und den Code innerhalb der Funktions eins zu eins kopieren.

Ich denke Shade Of Mine meint das so das er bei der ersten Methode sehen kann welche Funktion den Wert setzt und welche Funktion den wert zurückgibt. Und der Sinn der Überladung ist es imho nicht eine Wert-Setzende durch eine Wert-Liefernde Funktion zu ersetzen, sondern Funktionen mit der selben Funktionweise, z.B. wird bei der einen setzen-funktion ein standardwert gesetzt und bei der Überladung ein vom Benutzer einzugebener wert.

Code-Hacker

Sehe ich genauso. Ich bin eindeutig für get und set als Namenpräfixe.

rüdiger

Das ist so ein typischer Flamewar Punkt. Jeder Style hat seine Vor- und Nachteile. Was man wie macht muss jeder Programmierer für sich entscheiden (bzw. den Regeln des Projektes folgen :))

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.

Vellas

kingruedi schrieb:

Wozu ich da extra get oder set vorschreiben sollte ist mir schleierhaft.

Alles eine reine Geschmackssache.

Code-Hacker

Walli

Also wenn ich keinen setter brauche dann schreibe ich foo() anstatt getFoo(). Bei mir impliziert getFoo() auch immer, dass es ein setFoo(...) gibt.

Erhard Henkes

Ganz klar get/set bevorzugen, da es eindeutig die Richtung der Informationsübertragung signalisiert. Man sollte sinnvolle Dinge nicht verwerfen, nur weil sie nicht mehr in Mode sind.

Walli

@Erhard: Niemand will get/set verwerfen. Es ging neulich lediglich darum, dass viele Leute zu viel von ihrer Implementation preisgeben duch unsinnige get/set-Methoden.

MaSTaH schrieb:

@Erhard: Niemand will get/set verwerfen. Es ging neulich lediglich darum, dass viele Leute zu viel von ihrer Implementation preisgeben duch unsinnige get/set-Methoden.

Diese Argumentation verstehe ich nicht. Wenn ich die Methode kraft() überlade, so dass man kraft setten und getten kann, geb ich genau das selbe Preis.
Man kann ja wohl davon ausgehen, dass der Benutzer der Klasse weiss, was die Methode bewirken soll. WIE sie es bewirkt, ist in beiden Fällen nicht zu erkennen.

Walli

Es geht darum Selektoren grundsätzlich zu reduzieren an Stellen wo sie unnötig sind. Wenn du 4 Methoden hast:
getFoo
setFoo
getFooBar
setFooBar

dann betreibst du nicht gerade information hiding, weil der Benutzer dadurch weiß: "Ah, die Klasse hat also ein Foo und ein FooBar." Damit hast du unter Umständen schon zu viel von deiner Implementation preis gegeben. Das ist im Prinzip nicht viel besser als public-Variablen. An vielen Stellen kann/muss man allerdings getter und setter benutzen. Aber weniger ist manchmal halt mehr.

PS: HumeSikkins hat neulich einen interessanten Artikel dazu gepostet.

EDIT: Habe ihn gefunden...
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?

Erhard Henkes

Der Artikel trifft einen wesentlichen Punkt: Kapselung von Objekten.

Allen Holub: "... it's best to minimize data movement as much as possible. My experience is that maintainability is inversely proportionate to the amount of data that moves between objects."

Aber, wenn man schon die getadelten Akzessoren bastelt, dann bitte klar erkennbar, damit man diese im Sourcecode mit Suche nach setX/getX auch alle leicht findet.

Ich denke, wir sind da prinzipiell der gleichen Meinung. Alles andere ist Geschmacksache.

MaSTaH schrieb:

Es geht darum Selektoren grundsätzlich zu reduzieren an Stellen wo sie unnötig sind. Wenn du 4 Methoden hast:
getFoo
setFoo
getFooBar
setFooBar

dann betreibst du nicht gerade information hiding, weil der Benutzer dadurch weiß: "Ah, die Klasse hat also ein Foo und ein FooBar."

Das ist so nicht richtig. Wenn ich eine Klasse für komplexe Zahlen habe und eine Methode setRealTeil() anbiete, weiss der Anwender der Klasse trotzdem nicht, ob ich die Zahl in Polarkoordinaten speichere oder als Real- und Imaginär- Teil speichere, oder eine ganz andere Möglichkeit verwende.
Und mir ist völlig schleierhaft, inwieweit dann ein überladenes realTeil() die Situation verbessern soll.

Shade Of Mine

Optimizer schrieb:

Und mir ist völlig schleierhaft, inwieweit dann ein überladenes realTeil() die Situation verbessern soll.

garnicht. hat auch keiner behauptet.

es geht hier nur darum was schöner ist

setFoo/getFoo
oder
Foo() überladen

DrGreenthumb

alternativ wäre noch set_foo() und foo(). So mach ich's.

sry... aber das find ich verdammt sinnlos!
Ich bin für setX getX, weil das einfach für den DAU der klassen geeigneter ist. Ansonsten verliert so mancher den überblick....

Walli

Optimizer schrieb:

Das ist so nicht richtig. Wenn ich eine Klasse für komplexe Zahlen habe und eine Methode setRealTeil() anbiete, weiss der Anwender der Klasse trotzdem nicht, ob ich die Zahl in Polarkoordinaten speichere oder als Real- und Imaginär- Teil speichere, oder eine ganz andere Möglichkeit verwende.
Und mir ist völlig schleierhaft, inwieweit dann ein überladenes realTeil() die Situation verbessern soll.

Ich glaube wir haben mal wieder ziemlich aneinander vorbei geredet. Ich sprach von dem grundsätzlichen Sinn/Unsinn von verräterischen Selektoren und du von der Namensgebung. Um auf dein Beispiel mit der Klasse für die komplexen Zahlen zurück zu kommen: Es ist sicherlich sinnvoll getter/setter für Real- und Imaginärteil, bzw. für Betrag und Argument anzubieten. Die Namensgebung ist Sache des persönlichen Stils. Es gibt Argumente die für die überladene Version sprechen und solche dir für das get/set-Präfix sprechen. Ich persönlich finde es sinnvoller mir einen Namen zu überlegen der die Aktion beschreibt und über die Implementation null aussagt, z.B. anstatt auto.setFarbe(...) einfach auto.lackiere (blödes Beispiel, aber es sollte klar sein was ich meine ). Wenn mir keiner einfällt bevorzuge ich persönlich getFoo/setFoo als Präfix anstatt foo zu überladen.

nu is aber gut!

RHBaum

Aehm SOrry, koennt mir mal einer auf die Spruenge Helfen ?

Sinn/Unsinn von verräterischen Selektoren

Damit hast du unter Umständen schon zu viel von deiner Implementation preis gegeben.

Wieso sollte ich Internas an einem object verstecken wollen, wenn ich es fuer andere doch irgendwie zugaenglich machen muss/soll ?
Wenn es sich um das selbe Object handelt, krieg ich doch die implementationsdetails soweiso durch den Header raus ?
Wenn ich das verhindern will, nehm ich ne Proxy Klasse (PIMPL Idom) damit muss ich gar nix ueber die impl nach aussen geben ...
Verstehe die Argumentation nur nicht ganz.

Ich bin eher der Meinung lieber ein getter/setter mehr als public members. Mann weiss nie, was man spaeter mal zwischenschieben muss, so muss man wenigstens den eignen code nur anfassen, und die schnittstelle ist wesentlich stabiler.

Ob nun get_Kraft() / set_Kraft(x) oder Kraft()/Kraft(x) ist meiner meinung nach totale Geschmackssache. Basic Fans lieben sicher die 2. Variante. Ich arbeite viel mit der ATL, und bekomme da automatisch soweiso immer nen get_ set_ vor generiert, also halt ich mich im allgemeinen lieber daran ....

Ciao ...

Shade Of Mine

@RHBaum:

Lies doch bitte einfach den Artikel.

getter und setter sollen überlegt eingesetzt werden! Denn viele Leute verwenden für jede member variable auch gleich getter und setter.
Und niemand redet von public Variablen.

BTW: wenn man die internas einer Klasse erfahren will, dann kann man sie erfahren. es geht bei information hiding nicht darum die informationen gegen mutwillige angriffe zu schützen.

Bashar

RHBaum schrieb:

Ob nun get_Kraft() / set_Kraft(x) oder Kraft()/Kraft(x) ist meiner meinung nach totale Geschmackssache. Basic Fans lieben sicher die 2. Variante.

Dann waren die Leute vom Standardisierungskommitee wahrscheinlich Basic-Fans. Es gibt in der Standardlibrary zwar ein paar Funktionen, die mit get anfangen ... aber ich bezweifle, dass get, getline von istream oder get vom auto_ptr wirklich in das Standardraster der get-Funktionen rein passen Einzige Ausnahme: ios_base::getloc.
Ansonsten herrschen eher Namen wie name, what, size, length, flags, begin, end vor. Oder auch rdbuf.

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 ...