Name von Getter und Setter

Jetzt interessiert mich aber auch mal wie ihr Getter und Setter bennent. Bei mir ist es meist so:

int value();     // Getter für den Wert value
void value(int); // Setter für den Wert value

Singender Holzkübel

Ich verwende ganz gerne diesen komischen Stil:

class Foo
{
protected:
  Bar mBaz;
public:
  const Bar &Baz() const { return mBaz; }
  Bar &Baz() { return mBaz; }
};

dot

struct Blub
{
  int value;
};

Eisflamme

Ich hab gerade set und get, würde es im nächsten Projekt aber wie bei QT mit value() und setValue() machen. value(int) empfinde ich als nicht-sprechend.

hustbaer

GetValue und SetValue.
Und dumme POD structs verbastle ich natürlich auch nicht künstlich in Klassen mit Gettern und Settern.

asc

In unseren Projekt: SetValue, GetValue

Und ich gehöre zu denen, die Getter/Setter per se auch nicht als böse ansieht (oder Properties in anderen Sprachen), wenn eine Änderung/Abfrage von Einzelwerten sinnvoll ist (Und möglicherweise noch Bereichsprüfungen etc. erfolgen sollen - Nachträgliches ändern ist in C++ leider recht schlecht im Gegensatz zu Sprachen die Properties erlauben).

Fytch

Singender Holzkübel schrieb:

Ich verwende ganz gerne diesen komischen Stil:

Inwiefern trägt das irgendetwas zur Kapselung bei? Da kann man den Memer gleich public machen. Die Idee ist ja dass man später etwas an der Implementierung ändern kann (z.B. beim Setter eine Assertion einfügen) ohne dass das Interface davon betroffen wird. Mit der Referenz funktioniert das nicht und mit einem Proxy nur bedingt (man könnte die Adresse des Members nehmen wollen um ihn dann zu einem komplett anderen Zeitpunkt zu ändern) und unnötig umständlich.

@Topic:
Wenn ich welche brauche, dann verwende ich den Stl-Stil:

int Value() const;
int Value(int);

volkard

will ich get, heißt es get und ist get.
will ich set, heißt es set und ist set.

ich raff's nicht, daß man das verklausulieren will.

Das kleine Projekt Qt hat es halt das Verb set nur beim Setter behalten und auch der Qt-Creator, mit dem man ja Getter/Setter nicht selbst schreiben muss, schlägt das so vor.

Was auch noch bei der Arbeit mit dem Creator Spaß macht, neben dem Refacoring von Membern, Methoden und Klassen, ist das automatisch Herausnehmen von Definitionen. Also man schreibt seine Klasse, ohne Trennung von Deklaration und Definition, und wenn man fertig ist, dann lässt man die Definition(inklusive Code) raus nehmen und der Creator macht eine Deklaration und unter der Klasse setzt er dann die Definition hin, so dass man dann nur mit Cut & Paste eine Header- und Source-Datei erstellen kann. Früher wurde das tatsächlich mit Cut&Paste gemacht, wie rückständig würde Scotty da sagen^^

Singender Holzkübel

asfdlol schrieb:

Singender Holzkübel schrieb:

Ich verwende ganz gerne diesen komischen Stil:

Inwiefern trägt das irgendetwas zur Kapselung bei? Da kann man den Memer gleich ...

Stimmt, macht tatsächlich keinen Sinn. Keine Ahnung wo/wann/wieso ich mir das angeeignet habe.

Mechanics

Singender Holzkübel schrieb:

Stimmt, macht tatsächlich keinen Sinn.

Das muss jetzt nicht komplett sinnfrei sein. Ich will diesen komischen Stil nicht verteidigen und ich würde ihn auch nicht benutzen. Aber eine Funktion statt einem Member kann immer irgendwas kapseln. Die Funktion könnte vorher irgendwas initialisieren, loggen, locken, cachen usw. Und wenn man eine Funktion hat, kann man das immer noch ändern, ohne die Schnittstelle zu ändern.

Dumme Frage,

was hat das mit dem struct- Konstrukt mit get/set auf sich!?

SeppJ

NullBockException schrieb:

Dumme Frage,

Nein, schlechte Frage. Denn sie ist nicht verstaendlich. Ich habe keine Ahnung, was du wissen moechtest. Hol mal ein bisschen weiter aus bei deinen Fragestellungen. Wir kennen dich nicht; wir wissen nicht, auf welchem Niveau du bist; wir koennen nicht in deinen Kopf gucken, was du meinst.

I am sorry:)

"dot" hat hier geposett:

C++:
struct Blub
{
int value;
};

und ich frage mich was er damit meint bezgl. getter und setter:)

SeppJ

NullBockException schrieb:

I am sorry:)

"dot" hat hier geposett:

C++:
struct Blub
{
int value;
};

und ich frage mich was er damit meint bezgl. getter und setter:)

Wenn man sowieso zu jedem Attribut einen (trivialen) Getter und Setter schreiben will, dann ist das nicht anders, als wenn man alles public macht. Und das struct nimmt man deswegen ueber einer class + public, weil per defaul alles public ist und es deswegen eine durchaus uebliche Konvention ist, ein struct zu nehmen, wenn man einen Datentyp moechte, bei dem alles public ist (oder bei etwas strikterer Auslegung der Konvention, wenn man einen POD-Typ moechte (d.h. alles public und keine Methoden (die genaue Definition von POD ist etwas komplizierter, aber das ist der Kern der Definition))).

Hi sepp, danke für deine ausführung!

Wenn ich aber eine Klasse hätte,

und da meine Member mit public modifiziere, welche ich als "Property" sehe, geht das ja auch oder?

In einem struct wären ja dann alle member public (per default) und ich würde die member mit private modifizieren welche ich nich als "Property" interpretiere!

Oder hab ich das jetzt nich verstanden, was du gemeint hast??

hustbaer

Ob du class oder struct schreibst ist egal. Der einzige ist dass der Default Access bei class private ist und bei struct public .

NullBockException schrieb:

und da meine Member mit public modifiziere, welche ich als "Property" sehe, geht das ja auch oder?

In einem struct wären ja dann alle member public (per default) und ich würde die member mit private modifizieren welche ich nich als "Property" interpretiere!

Ich sag mal: entweder alles (alle Membervariablen) public oder alles private (bzw. bei Klassen die zum Ableiten gedacht sind ist eine Mischung aus private und protected natürlich auch OK).
Gibt natürlich immer wieder mal Ausnahmen wo es wirklich Sinn machen kann in einer Klasse die private Membervariablen hat ein paar Membervariablen public zu machen. Wobei ich dann eher vorziehe sinnlose Getter/Setter zu implementieren. Und oft kommt sowas nicht vor.

Eben, so würde ich es auch machen.. ! Aber dadurch dass ich schon laange in C# programmiere, und c++ länger nicht mehr angefasst habe, würde ich schon rein instinktiv mit vielen gettern/settern arbeiten, da ich ja aus c# "Properties" gewöhnt bin:)

Nathan

NullBockException schrieb:

Eben, so würde ich es auch machen.. ! Aber dadurch dass ich schon laange in C# programmiere, und c++ länger nicht mehr angefasst habe, würde ich schon rein instinktiv mit vielen gettern/settern arbeiten, da ich ja aus c# "Properties" gewöhnt bin:)

Ja, aber das ist die klassische Getter/Setter Diskussion:
Bei Klassen mit Memberfunktionen, brauchen nur manche Membervariablen Getter und noch weniger Setter, viel wichtiger sind "normale" Funktionen.
Wenn du für jede Variable Getter und Setter hast, ist es meistens besser daraus eine struct zu machen und alle Variablen öffentlich.

wenn man allzuviele getter und setter braucht, ist das für mich ein Indiz, über die Objekt-Modellierung nachzudenken und ggf zu refaktorisieren.