Name von Getter und Setter

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.

Es geht doch hier nicht darum, wer wie viele Getter/Setter einbaut und ob das Sinn macht. Es geht hier um eine Frage zur Namenskonvention.

hustbaer

@GetSetWilly
Ich empfinde es schon als Fortschritt, dass sich hier keiner blöd von der Seite anmachen lassen musste, nur weil er es wagt sich Gedanken über solche "unwichtigen" Dinge wie Benamsung/Formatierung/... zu machen.

Hatten wir nämlich auch ne Zeit lang.

cooky451

hustbaer schrieb:

GetValue und SetValue.

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

@hustbaer:
Es gibt ja mittlerweile sogar schöne Bücher darüber, wie "Weniger schlecht Programmieren" von OReilly.

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

cooky451

GetSetWilly schrieb:

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.

hustbaer

Ist aber auch ein Vortail dass es anders aussieht.
Sieht man wenigstens gleich was eigener Code bzw. ThirdParty Code ist.