Warum getter und setter funktionen in c++

[Bernd (Gast)]

hallo,
was ist der vorteil von getter und setter funktionen in C++? bzw. Warum 
macht man das? Man könnte die Variablen doch auch direkt 
beschreiben/abfragen.

objekt A()
...
int x = A.getValue();
A.setValue(25);


int objekt::getValue()
{
  return _value;
}

void objekt::setValue(int x)
{
  _value = x;
}

Warum beschreibt man die Variable nciht sofort?

int x = A._value;
A._value = 25;

Bernd

[Olaf B. (Firma: OBUP) (obrecht)]

Bernd schrieb:
> was ist der vorteil von getter und setter funktionen in C++

Prinzip der Datenkapselung/Information hiding.

s.a.: https://de.wikipedia.org/wiki/Datenkapselung_(Programmierung)

Abschnitt Vorteile.

mfg

Olaf

P.S.: in set...(...) bitte Variablen als const deklarieren.

[Dr. Google (Gast)]

man muss es nicht machen. die leute haben java gelernt oder .net und nun 
machen sie das gleiche mit c++.
c++ ist für anwenungsprogrammierung. systemprogrammierung in c kennt 
auch objekte z.b. /dev /proc in linux.

[rmu (Gast)]

Wirklich Sinn macht das nur, wenn im setter/getter mehr passiert als nur 
das Schreiben einer Variablen, oder die setter/getter virtuell sein 
müssen. Beispielsweise überprüfung eines Wertebereichs, irgendeine Art 
von Speicherverwaltung, Serialisierung des Zugriffs bei nicht-atomaren 
Datentypen etc...

Ansonsten ists nur eine Schreibübung bzw. Übung für die IDE die den Code 
nicht unbedingt übersichtlicher macht.

getter unbedingt const und noexcept machen.

[Da D. (dieter)]

Olaf B. schrieb:
> Prinzip der Datenkapselung/Information hiding.

Häufig wird es nur aufgrund der "reinen Lehre" gemacht. Da kommen dann 
so abstrakte Begründungen raus, wie die zitierte. Aber es gibt durchaus 
reale Gründe für getter/setter. Die sind aber vom konkreten Fall 
abhängig, und nicht mit so einer Pauschalregel abzuhandeln.

Unter folgenden Voraussetzungen bringen getter/setter keinen Vorteil:
1) Die getter/setter würden vollen public Zugriff auf eine 
Membervariable geben. Und
2) In den getter/setter Methoden passiert nichts weiter, außer den Wert 
zu setzen oder zu schreiben. Wenn aber noch irgendwelche zusätzlichen 
internen Verwaltungsaufgaben in der Klasse gemacht werden, sollten diese 
auf jeden Fall in so einer getter/setter Methode gekaselt werden.

In deinem Trivialbeispiel ind die getter/setter tatsächlich unnötig.

[Johannes S. (Gast)]

mit get/set kann man einfacher nachträglich die Funktion ändern ohne das 
Interface verändern zu müssen. Z.B. wenn jetzt x = _value * 1.1 sein 
soll kann man das in objekt einbauen ohne jetzt alle Aufrufer anpacken 
zu müssen.

[Bernd (Gast)]

Da D. schrieb:
> Unter folgenden Voraussetzungen bringen getter/setter keinen Vorteil:
> 1) Die getter/setter würden vollen public Zugriff auf eine
> Membervariable geben. Und
> 2) In den getter/setter Methoden passiert nichts weiter, außer den Wert
> zu setzen oder zu schreiben. Wenn aber noch irgendwelche zusätzlichen
> internen Verwaltungsaufgaben in der Klasse gemacht werden, sollten diese
> auf jeden Fall in so einer getter/setter Methode gekaselt werden.

Johannes S. schrieb:
> mit get/set kann man einfacher nachträglich die Funktion ändern ohne das
> Interface verändern zu müssen. Z.B. wenn jetzt x = _value * 1.1 sein
> soll kann man das in objekt einbauen ohne jetzt alle Aufrufer anpacken
> zu müssen.

Ich danke euch für eure erklärungen. So etwas in dieser Richtung habe 
ich mir schon gedacht.

[Rufus Τ. F. (rufus)]

Getter/Setter sind allerdings auch eine Hilfe beim Debuggen - um 
Schreibzugriffe auf die Variable abzufangen, genügt genau eine 
Debugausgabe im Setter.

Da wäre der direkte Variablenzugriff quer durch den Code zerstreut nur 
mit einem Debugger abfangbar, der Breakpoints auf Datenzugriffe setzen 
kann.

[Nase (Gast)]

Real teilt sich die Welt etwa so:
(a) PODs, also Objekte die eher Strukturen sind und "nur" Daten 
zusammenhalten. Dort greift man meistens direkt auf die Member zu. Daher 
trifft "Struktur" es ganz gut, denn dort sind die ohnehin alle public.
(b) Objekte. Da überwiegt in aller Regel der Teil an Settern, wo noch 
mehr passiert. Also macht man konsequenterweise alles per Setter/Getter.

Es kann aber noch andere Gründe geben: Mit einem Getter kannst du 
Kopieren erzwingen, d.h. es kann keiner einen Zeiger oder eine 
(nicht-rvalue-)Referenz in dein Objekt erstellen.

[Mugl (Gast)]

Es gibt konkrete und abstrakte Datentypen. Bei abstrakten Datentypen 
darf nicht direkt auf die Implementierung zugegriffen werden können. Es 
gibt nur eine Interface das verwendet wird.
Dadurch werden Invarianten sichergestellt. zB muss ein Wertebereich 
überprüft werden oder es müssen Synchronisations Mechanismen 
berücksichtigt werden(Multithreading).
zB in C sind bei einer verketteten Liste die Zeiger beschreibbar(wenn 
nicht mit malloc gearbeitet wird). Ein setzten des Zeigers ist aber nur 
in gewissen Situation erlaubt wie zB in Funktionen push, pop, add. Hier 
ist es nicht erwünscht das irgendwer von aussen Zugriff auf die Zeiger 
bekommt.
das ist in C nicht realisierbar.

[Wilhelm M. (wimalopaan)]

Statt getter/setter sagt man im C++-Kontext auch gerne Observer/Modifier 
bzw. Beobachter/Mutator, was m.E. bessere Bezeichnungen derartiger 
Funktionen sind.

Denn im Gegensatz zu bspw. Java ist das const Bestandteil der Signatur 
und kennzeichnet die Elementfunktion klar als Beobachter. Versuche ich 
ein const-Objekt zu verändern mit einem Mutator (aka setter, ohne 
const), dann widerspricht das der const-correctness und kann nicht 
übersetzt werden. Und const-correctnes ist ein ganz hohes Gut bei C++! 
Deswegen wird auf die Vorsilbe "get..." oder "set" oft verzichtet. Bei 
C++ prüft das der Compiler und nicht der Mensch.

Ein Beobachter liefert Information über das Objekt, das kann auch etwas 
Berechnetes sein wie etwa der Flächeninhalt aus den Attributen Höhe und 
Breite.

Die Datenelemente einer Klasse sind die interne (!) Repräsentation des 
Objektzustandes: und diese interne Repräsentation sollte nicht durch den 
"wahllosen" Einsatz von sog. gettern nach aussen transportiert werden.

Noch schlimmer ist allerdings der "wahllose" Einsatz von settern: ein 
Mutator (setter) soll den beobachtbaren Zustand eines Objektes setzen. 
Dabei sind sicher nicht alle Wertekombinationen der Datenelemente 
erlaubt. Einen gültigen Zustand (nach einer Veränderung) aber 
sicherzustellen, genau das ist die Aufgabe der Mutatoren.

Sinnvollerweise bekommen die setter Zusicherungen (Assertionen), um ggf. 
die Gültigkeit der Parameterwerte sicherzustellen (Vorbedingung) und am 
Ende des Mutators auf einen gültigen Objektzustand zu prüfen 
(Nachbedingung).

[Wilhelm M. (wimalopaan)]

Bernd schrieb:
> hallo,
> was ist der vorteil von getter und setter funktionen in C++? bzw. Warum
> macht man das? Man könnte die Variablen doch auch direkt
> beschreiben/abfragen.
>
>

> objekt A();
> ...

>

>

Zur Info:

Und die obige Zeile definiert keine Variable A vom Typ objekt. Sondern 
deklariert eine Funktion A() mit leerer Parameterliste und Rückgabetyp 
objekt ...