innerhalb Klasse: direkt zugreifen oder get-/set-Methode ?

Guten Abend,

Bsp.:

class Foo
{
    private:
        int attribut;

    public:
        Foo(const Foo& ori)
        {
            this->attribut = ori.attribut; // so...

            this->attribut = ori.getAttribut(); // ...oder so ?
        }

        int getAttribut() const
        {
            return attribut;
        }
};

int main()
{
    return 0;
}

Ich wollte mal fragen, wenn man sich innerhalb der Klasse befindet, ob man besser direkt auf die Attribute zugreift oder eine get-Methode /set-Methode verwendet ?

Welche Variante verwendet ihr ?

setMethoden innerhalb der Klasse zu verwenden finde ich unschön,
getMethoden zu benutzen finde ich dagegen ganz ok, wobei man dann aber nicht mehr ganz einheitlich ist. Also wenn dann ganz oder gar nicht ?

grüßle

unskilled

this->attribut = ori.attribut; // so...
das hier verwende ich - allerdings in der initialisierungsliste:

struct foo
{
  int get_x() const { /*....*/ }

  foo(const foo& other)
  : x(other.x)
  {}
private:
  int x;
};

Hintergrund: Es kann ja gut sein, dass ich in get_x noch iwas für den User anpasse/umwandel/runde/...

(wobei klar sein sollte, dass ich in dem Fall den vom Compiler generierten Copy-CTor nutzen würde)

bb

solange getAttributE() nicht virtual ist, bevorzuge ich den direkten Zugriff...

Bashar

Direkt. Wenn man das Gefühl hat, dass gerade eine get/setMethode besser wäre als der direkte Zugriff, liegt das wahrscheinlich daran, dass die Klasse zu unübersichtlich geworden ist. Für mich ist das ein Warnzeichen.
Wenn ich irgendwo ein /*this->*/getFoo() sehe, denk ich automatisch erstmal protected .

unskilled

OleInPuffNachBarca schrieb:

solange getAttributE() nicht virtual ist, bevorzuge ich den direkten Zugriff...

virtuelle fkt. im ctor/dtor aufrufen? oO

Nexus

Meistens auch direkt. Wenn ein Getter aber was Komplizierteres ausrechnet oder eine grosse Wahrscheinlichkeit hat, dass sich die Implementierung bald ändert, dann rufe ich ihn auf.

Beim Setter analog.

fr33g

Ich nehm im Normalfall auch die direkte Variante, außer es steckt etwas komplizierteres wie eine berechnumg dahinter, wenn ich dann dafür eine passende get-methode habe nutze ich diese dann auch.

Lg freeG

unskilled

fr33g schrieb:

Ich nehm im Normalfall auch die direkte Variante, außer es steckt etwas komplizierteres wie eine berechnumg dahinter, wenn ich dann dafür eine passende get-methode habe nutze ich diese dann auch.

Lg freeG

was habt ihr nur alle immer mit euren berechnungen?
es geht hier doch um nen copyctor, oder?
als ob man - um an die member-variablen zu kommen - iwas rumrechnen müsste. man hat sie doch schon...
selbst, wenn man komplizierte berechnungen beim getter hat, sind die doch max. für den nutzer nötig...
oder kann mir jmd nen ggn-beispiel nennen?

bb

unskilled schrieb:

was habt ihr nur alle immer mit euren berechnungen?
es geht hier doch um nen copyctor, oder?

aso nein, meinte das eher allgemein der copy-ctor kam mir grad iwie nur gelegen.

fr33g

unskilled schrieb:

fr33g schrieb:

Ich nehm im Normalfall auch die direkte Variante, außer es steckt etwas komplizierteres wie eine berechnumg dahinter, wenn ich dann dafür eine passende get-methode habe nutze ich diese dann auch.

Lg freeG

was habt ihr nur alle immer mit euren berechnungen?
es geht hier doch um nen copyctor, oder?
als ob man - um an die member-variablen zu kommen - iwas rumrechnen müsste. man hat sie doch schon...
selbst, wenn man komplizierte berechnungen beim getter hat, sind die doch max. für den nutzer nötig...
oder kann mir jmd nen ggn-beispiel nennen?

bb

Ich hab zum Beispiel mehrere Membervariablen und jetzt brauch ich eben das Ergebnis einer Rechnung mit diesen Variablen.
So und wenn der Benutzer eben diese Berechnung auch braucht und sie als getter Funltion zur Verfügung steht, nehm ich sie auch, anstatt alles nochmal selber zu berechnen.

Lg freeG

Nexus

unskilled schrieb:

als ob man - um an die member-variablen zu kommen - iwas rumrechnen müsste. man hat sie doch schon...

Seit wann müssen Getter Membervariablen zurückgeben? Oder was, wenn diese gecacht sind ( mutable )?

unskilled schrieb:

oder kann mir jmd nen ggn-beispiel nennen?

Das einzige, was ich auf die Schnelle gefunden habe, ist eine grafische Pfeil-Klasse von mir. Dabei gibt GetTriangleHeight() die Höhe des gleichschenkligen Dreiecks an der Pfeilspitze zurück.

float Arrow::GetTriangleHeight() const
{
	return 4.f * myThickness;
}

Die Implementierung ist nicht kompliziert, aber wenn ich dann plötzlich die 4.f ändere, will ich das an einem Ort tun und nicht an vier verschiedenen.

Was soll daran bitte schlecht sein?

unskilled

Was soll daran bitte schlecht sein?

das es (für mich) den eindruck machte, als ob es nur um den copy-ctor gänge - und da sind ja 0 berechnungen nötig - da alle daten, die man braucht, um die klasse zu konstruieren schon existieren.

wenns nicht nur darum geht, zu kopieren, würde ich vrmtl die getter bevorzugen.

bb

unskilled schrieb:

OleInPuffNachBarca schrieb:

solange getAttributE() nicht virtual ist, bevorzuge ich den direkten Zugriff...

virtuelle fkt. im ctor/dtor aufrufen? oO

Was spricht dagegen?
Wird ja auf dem Parameter aufgerufen...

OleInPuffNachBarca schrieb:

unskilled schrieb:

OleInPuffNachBarca schrieb:

solange getAttributE() nicht virtual ist, bevorzuge ich den direkten Zugriff...

virtuelle fkt. im ctor/dtor aufrufen? oO

Was spricht dagegen?
Wird ja auf dem Parameter aufgerufen...

http://www.artima.com/cppsource/nevercall.html

Nexus

Dweb schrieb:

http://www.artima.com/cppsource/nevercall.html

Das gilt für this , aber nicht für andere Objekte.

Nexus schrieb:

Dweb schrieb:

http://www.artima.com/cppsource/nevercall.html

Das gilt für this , aber nicht für andere Objekte.

agree