Unterschied zwischen get und set (C++)

Was ist der Unterschied zwischen "get" und "set" ??

Ich habe mal bissi recherchiert und habe folgendes ausprobiert (bsp. Taschenrechner):

...::setZahl1 (int zahl1)
{
   zahl1 -> Edit1->Eingabe;
}

...::getZahl1()
{
  return zahl1;
}

Also mit set deklariert man und mit get gibt man den Wert zurück.
Stimmt es ??

_matze

Mit set-Methoden weist man üblicherweise den Wert zu, und mit get gibt man ihn zurück, ja. Natürlich sind Namen Schall und Rauch, d.h. wenn jemand eine get-Methode anders implementiert, funktioniert sie halt anders. Aber im Normalfall ist es so.

Artchi

Für gewöhnlich sollte natürlich die Funktion das tun, was sie auch aussagt. Wenn eine Funktion add(int, int) sollte sie sinnvollerweise auch addieren und nicht multiplizieren.

Manche lassen auch das get/set weg:

void A::zahl1(int z1)
{
   // ..
}
int A::zahl1() const
{
   // ..
}

314159265358979

Meiner Meinung nach sind getter und setter das letzte, was man braucht.

Setter kann man meistens gut umgehen, z.B. "window.move(x, y)" statt "window.setPosition(x, y)". Oder auch .resize(x, y) statt .setSize(x, y). Meiner Meinung nach sind Funktionen, die eine Tätigkeit beschreiben besser, als ein "setX".

Bei gettern lasse ich das "get" einfach weg. "window.position()", "window.size()" wären Beispiele.

Ist aber wie gesagt nur meine Sicht der Dinge

Jodocus

314159265358979 schrieb:

Meiner Meinung nach sind getter und setter das letzte, was man braucht.

Setter kann man meistens gut umgehen, z.B. "window.move(x, y)" statt "window.setPosition(x, y)". Oder auch .resize(x, y) statt .setSize(x, y). Meiner Meinung nach sind Funktionen, die eine Tätigkeit beschreiben besser, als ein "setX".

Bei gettern lasse ich das "get" einfach weg. "window.position()", "window.size()" wären Beispiele.

Ist aber wie gesagt nur meine Sicht der Dinge

Womit wir wieder beim Thema "Namen sind nur Schall und Rauch" wären...

hustbaer

314159265358979 schrieb:

Meiner Meinung nach sind getter und setter das letzte, was man braucht.

Setter kann man meistens gut umgehen, z.B. "window.move(x, y)" statt "window.setPosition(x, y)". Oder auch .resize(x, y) statt .setSize(x, y). Meiner Meinung nach sind Funktionen, die eine Tätigkeit beschreiben besser, als ein "setX".

Bei gettern lasse ich das "get" einfach weg. "window.position()", "window.size()" wären Beispiele.

OK, du nennst deine Funktionen anders. Ob das gut oder schlecht ist, darüber kann man unterschiedlicher Meinung sein, ist aber (mir zumindest) hier mal egal.
Ändert allerdings nichts daran, dass es nach wie vor Setter bzw. Getter sind.

----

ps: ich verstehe "move" und "setPosition" auch anders. "set position" impliziert absolute Koordinaten, "move" impliziert relative. Wenn du nur "move" mit relativen Koordinaten anbietest, dann fehlt IMO was. Und wenn du "move" mit absoluten anbietest, dann ist der Name mMn. schlecht gewählt.

hustbaer schrieb:

"set position" impliziert absolute Koordinaten, "move" impliziert relative.

Genau, deshalb verwende ich für setPosition auch eher move_to.

Wenn man sich auch nur annähernd an den Stil der Standardlib anpasst, gehören Setter nicht in den Code.

314159265358979

War doch nur ein Beispiel, ich würde auch eher move_to bzw move_by verwenden

Ein "get" drückt für mich aus, dass da irgendwas berechnet werden muss, oder der Wert von irgendwo eingelesen werden muss. Deshalb passt mir get zum zurückgeben von Membern nicht in den Kram. Wenn was berechnet werden soll, dann heißt die Funktion "calculate_x". Wenn was zurückgegeben wird, dann einfach nur x.

Vielleicht hab ich auch zusätzlich ne Allergie gegen getter/setter, weil die in Java so oft verwendet werden. Wer weiß.

volkard

314159265358979 schrieb:

Ein "get" drückt für mich aus, dass da irgendwas berechnet werden muss, oder der Wert von irgendwo eingelesen werden muss. Deshalb passt mir get zum zurückgeben von Membern nicht in den Kram. Wenn was berechnet werden soll, dann heißt die Funktion "calculate_x". Wenn was zurückgegeben wird, dann einfach nur x.

Weiß nicht.
get ist Member-Holen
calc ist Berechnen
read ist Einlesen
So könnte man es auch machen.

314159265358979 schrieb:

War doch nur ein Beispiel, ich würde auch eher move_to bzw move_by verwenden

warum hast du dann nicht gleich move_to oder so geschrieben ?

314159265358979 schrieb:

Vielleicht hab ich auch zusätzlich ne Allergie gegen getter/setter,...

wenn das so wäre, dann wuerdest du setter und getter funktionen gar nicht verwenden. egal wie sie heissen.
bei deinen beiträgen könnte man oftmals denken, das du nur irgendwas schreibst um deinen beitragszähler hoch zuschrauben

314159265358979

2,718281828459045235 schrieb:

warum hast du dann nicht gleich move_to oder so geschrieben ?

Weil ich besseres zu tun habe, als zu überlegen, ob dir der Funktionsname passt.

2,718281828459045235 schrieb:

wenn das so wäre, dann wuerdest du setter und getter funktionen gar nicht verwenden. egal wie sie heissen.

Ich verwende sie nicht, ich gebe meinen Funktionen sinnvolle und sprechende Namen, die entweder eine Tätigkeit beschreiben, oder wie der Zugriff auf einen Member aussehen.

brotbernd

class Foo
{
private:
  int i;

public:
  int Bar() {return i;}
  void Baz(int value) {i = value;}
};

Bar ist ein Getter und Baz ein Setter, ganz egal wie die heißen. Nur weil sie anders heißen sind Barer&Bazer nicht plötzlich was besseres als Getter&Setter. Wie in vielen Klassen ist die Foo Klasse totaler Unsinn. Sie bietet keinerlei Kapselung keine Abstraktion garnix. Man kann was eingeben und wieder rausholen, toll.
In vielen anderen Situationen braucht man aber mal einen Setter. Oder einen Getter oder sogar beides. Getter/Setter sind sinnvoll, wenn man sie braucht, sonst nicht (übrigens hier schon ungefähr 1e42 mal diskutiert).
Wie man solche Methode benennt, ist ein ganz anderes Thema. Wahrscheinlich sogar das interessantere Thema. Wobei es, wie bei allen Konventionen vor allem darauf ankommt, dass sich alle Teammitglieder daran halten. Ob jetzt ein Getter get.. Get.. oder einfach nur ... heißt ist eher Geschmackssache.

Tachyon

brotbernd schrieb:

class Foo
{
private:
  int i;

public:
  int Bar() {return i;}
  void Baz(int value) {i = value;}
};
Wie in vielen Klassen ist die Foo Klasse totaler Unsinn. Sie bietet keinerlei Kapselung keine Abstraktion garnix. Man kann was eingeben und wieder rausholen, toll.

So gesehen stimmt das natürlich, aber Du könntest jetzt die interne Darstellung von i ändern, ohne das der potentielle Benutzer von Foo etwas davon mitbekommt.

314159265358979

Für oder gegen Getter und Setter argumentieren anhand von abstrakten Klassennamen wie "Foo" macht sowieso keinen Sinn.

brotbernd

Ich argumentiere überhaupt nicht für oder gegen Getter/Setter. Ich argumentiere gegen Die Meinung man würde keine Getter/Setter einsetzen, weil nirgendwo das Wort get oder set vorkommt.

_matze

314159265358979 schrieb:

Für oder gegen Getter und Setter argumentieren anhand von abstrakten Klassennamen wie "Foo" macht sowieso keinen Sinn.

Doch, macht Sinn. Ein gutes Argument hat Tachyon doch schon genannt.

314159265358979

Tachyons Argumentierung stimmt ja auch, darum gehts schließlich in OOP. Aber was ich damit ausdrücken wollte, war, dass man anhand so einer Klasse nicht für/gegen den namen get/set argumentieren kann. Mit konkreten Beispielen kann man argumentieren "hier sind get/set die besten Namen für Funktionen".

Aber wie schon hustbaer sagte, ist das eigentlich eine ziemlich sinnlose Diskussion. Jeder hat da andere Ansichten, ich habe da wohl eher eine exotische

(Übrigens, ich verwende glgtl. als Funktionsnamen nur "get" und "set". Das ist der Fall, wenn ich z.B. eine Klasse zur Repräsentation eine Config-Datei schreibe. Dann heißt die Funktion bei mir get(key) und der Setter set(key, value). Ist aber die einzige Ausnahme.)

_matze

314159265358979 schrieb:

Tachyons Argumentierung stimmt ja auch, darum gehts schließlich in OOP. Aber was ich damit ausdrücken wollte, war, dass man anhand so einer Klasse nicht für/gegen den namen get/set argumentieren kann. Mit konkreten Beispielen kann man argumentieren "hier sind get/set die besten Namen für Funktionen".

Ach so. Ich dachte, es geht nicht mehr um die Namen, sondern um die Funktion an sich.

314159265358979

Nein, getter und setter als solches sind vollkommen okay. Nur sollte man ihnen bessere Namen geben als getX/setX.

Es macht für mich einen Unterschied, ob ein Wert aus einem geparsten HTTP-Response kommt, oder von einem Member. Erstere Methode würde ich .retrieve_x() nennen, letztere .x(). Muss ein Wert berechnet werden, dann hieße sie eben .calc_x() oder .calculate_x().

Bei Settern sieht es ähnlich aus. Eine Methode .move_to() (wie oben erwähnt) drückt eine Tätigkeit aus. .set_position() ist eher nichtssagend. Auch bleiben hier Fragen offen. Wann bemerke ich die Positionsänderung? Wird das Fenster direkt geupdatet, oder erst bei im nächsten Rendervorgang?

Oder, um es zusammenzufassen: get/set drückt mir zu wenig aus. Da setze oder krieg ich einen Wert. Was dann aber konkret passiert, bleibt mir verborgen.

_matze

314159265358979 schrieb:

Was dann aber konkret passiert, bleibt mir verborgen.

Ist das nicht der Sinn von Abstraktion durch Klassen?