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

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

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

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);

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

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

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.

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

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.

"dot" hat hier geposett:

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

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

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

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

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:)

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.

Hatten wir nämlich auch ne Zeit lang.

GetValue und SetValue.

Leicht off-topic, aber: Du scheinst Methoden/Funktionen in CamelCase zu schreiben. Machst du das mit Typen und Variablen auch so?

@cooky451:
Gegen CamelCase spricht doch nichts, wird in Qt bis auf die Member nur so gemacht und ich finde das übersichtlich.

Gegen CamelCase spricht doch nichts

Ganz im Gegenteil, ich finde es eigentlich relativ hübsch, es sieht halt nur leider etwas doof aus zusammen mit stdlib-Code. das_gilt_aber_für_alles_was_nicht_so_aussieht.