Methodennamen setValue, SetValue oder set_value



  • Wo wir schon dabei sind, nach welchem Muster benennt ihr eure Methoden?



  • setValue.
    Allerdings bevorzuge ich es, ueberhaupt keine setter zu haben.



  • Wie keine Setter?



  • IDEFinder schrieb:

    Wie keine Setter?

    Nicht jede Membervariable braucht eine Setter und eine Getter. Manche brauchen nur Setter, manche nur Getter, manche gar nichts. Manche dinge gehörn logisch zusammen, sodass du sie in eine struct steckst.

    Und SeppJ tritt dir gleich auf die Füße.



  • Nehmen wir mal an, du willst eine Anschrift in deinem Programm haben. Wenn du dich jetzt gerade in deiner Ausbildung befindest, sagt dir dein Übungsblatt bestimmt du sollst für alles get + set machen (so wars bei mir früher mal). Nach paar Monaten/Jahren denkst du dir aber so ein Scheiß. Anstatt für alles get + set zu machen kannst du z.B.

    #include <string>
    #include <iostream>
    using namespace std;
    
    struct anschrift
    {
    	string name;
    	string strasse;
    	string hausnummer;
    	string ort;
    };
    
    ostream& operator<<( ostream& out, const anschrift& as )
    {
    	out << as.name    << '\n';
    	out << as.strasse << ' ' << as.hausnummer << '\n';
    	out << as.ort     << '\n';
    	return out;
    }
    
    int main()
    {
    	// Bei dieser Art von Klase kannst du Datenelemente ganz einfach bei der Objekterzeugung setzen.
    	anschrift hausmeister = { "Hans Maier", "Teststrasse", "11/2", "33015 Testort" };
    
    	// Ganz ohne Getter
    	cout << hausmeister;
    }
    


  • IDEFinder schrieb:

    Wo wir schon dabei sind, nach welchem Muster benennt ihr eure Methoden?

    Unabhängig von Settern/Gettern: Bleib einheitlich (Ob nun CamelCase, PascalCase oder was auch immer...).



  • @out: Ja, schon klar dass nicht jeder Member Getter oder Setter braucht. Ich meinte auch nur, wenn mal ein Member von außen gesetzt oder gelesen werden muss, wie dann die Namenskonvention bei euch dafür ist. Ich habe auch nicht in jeder Klasse Getter/Setter und bei manchen auch nur einen Getter oder einen Setter, dann habe ich aber auch Klassen mit ganz viele überladene Setter usw.



  • out schrieb:

    Und SeppJ tritt dir gleich auf die Füße.

    .. nicht nur SeppJ 😉
    guckst Du z.B. hier: http://www.c-plusplus.net/forum/313991-full



  • Ist doch alles BS. Der Informationsgehalt in den Woertern 'set' und 'get' ist genau 0. Eher sogar negativ, weil es verschleiert, was tatsaechlich passiert. Wird hier eine Netzwerkverbindung bemueht, oder ist das bloss direkter Zugriff auf einen Member?
    -> Wer get/set benutzt hat keine Ahnung.



  • Kellerautomat schrieb:

    Der Informationsgehalt in den Woertern 'set' und 'get' ist genau 0. Eher sogar negativ, weil es verschleiert, was tatsaechlich passiert. Wird hier eine Netzwerkverbindung bemueht, oder ist das bloss direkter Zugriff auf einen Member?

    Was soll einem Nutzer einer Schnittstelle interessieren, was genau in der Implementierung passiert? Gerade das, was du hier als schlecht darstellst, halte ich für ein gutes Beispiel was eben nicht in die Bezeichnung soll.

    Dies ist auch ein Beispiel für die Verwendung von Interfaces in anderen Sprachen: Man tauscht nur die Implementierung aus, je nach Notwendigkeit (ob nun auf lokale oder weit entfernte Daten zugegriffen werden soll) - das geht nur wenn man in den Methodenbezeichnungen eben nicht Implementierungsdetails einbaut.



  • asc schrieb:

    Was soll einem Nutzer einer Schnittstelle interessieren, was genau in der Implementierung passiert? Gerade das, was du hier als schlecht darstellst, halte ich für ein gutes Beispiel was eben nicht in die Bezeichnung soll.

    Das ist sogar sehr relevant. Ultra relevant. Als Benutzer eines Interfaces will ich Performance-Charakteristiken ablesen koennen. Ist zu erwarten, dass der Call mein GUI aufhaengt, wenn meine Internet Verbindung gerade langsam ist?
    Sowas ist verdammt wichtig.

    asc schrieb:

    Dies ist auch ein Beispiel für die Verwendung von Interfaces in anderen Sprachen: Man tauscht nur die Implementierung aus, je nach Notwendigkeit (ob nun auf lokale oder weit entfernte Daten zugegriffen werden soll) - das geht nur wenn man in den Methodenbezeichnungen eben nicht Implementierungsdetails einbaut.

    Um dann Szenarien zu bekommen wie in C#, wo die Leute LINQ verwenden und sich dann wundern warum ihre Queries so scheisse langsam sind.
    "Das Interface erforderte, dass ich Random Access auf Linked Lists implementiere"



  • Kellerautomat schrieb:

    asc schrieb:

    Was soll einem Nutzer einer Schnittstelle interessieren, was genau in der Implementierung passiert? Gerade das, was du hier als schlecht darstellst, halte ich für ein gutes Beispiel was eben nicht in die Bezeichnung soll.

    Das ist sogar sehr relevant. Ultra relevant. Als Benutzer eines Interfaces will ich Performance-Charakteristiken ablesen koennen.

    Die Betonung liegt hierbei eindeutig auf "ich". Es ist vermutlich nur den wenigsten wichtig eine monolitische Schnittstelle zu schaffen, nur damit man dieser die Performance ablesen kann. Wenn die Schnittstelle generisch bezeichnet wird, kann der Benutzer teilweise selbst zur Laufzeit entscheiden welche Variante er nutzt (z.B. Konfigurationseinstellung).

    Kellerautomat schrieb:

    asc schrieb:

    Dies ist auch ein Beispiel für die Verwendung von Interfaces in anderen Sprachen: Man tauscht nur die Implementierung aus, je nach Notwendigkeit (ob nun auf lokale oder weit entfernte Daten zugegriffen werden soll) - das geht nur wenn man in den Methodenbezeichnungen eben nicht Implementierungsdetails einbaut.

    Um dann Szenarien zu bekommen wie in C#, wo die Leute LINQ verwenden und sich dann wundern warum ihre Queries so scheisse langsam sind.

    Compiled Linq mag nicht die Performance vom SQL Data Reader erreichen, aber doch nahe genug um beileibe nicht von "scheisse langsam" zu reden.

    Davon abgesehen habe ich zumindest in meinen Projekten die Möglichkeit jederzeit die Option verschiedene Implementierungen auszutauschen, je nach dem was beim Anwendungsfall nun wichtig ist.



  • Kellerautomat schrieb:

    Das ist sogar sehr relevant. Ultra relevant. Als Benutzer eines Interfaces will ich Performance-Charakteristiken ablesen koennen. Ist zu erwarten, dass der Call mein GUI aufhaengt, wenn meine Internet Verbindung gerade langsam ist?
    Sowas ist verdammt wichtig.

    Da kannste Dich auf den Kopf stellen, das wird nix. Echte Experten machen keinen Unterschied zwwischen getName(), generateName(), readName(), calcName(), receiveName(), …
    Entsprechend auch setSize(), resize(), grow(), reserve(), storeSize(), writeSize(), sendSize(), transmitSize(), printSize()…
    Es geht den Benutzer nichts an, und je weniger das Kund erfährt, desto besser wird alles werden. Noch gehen sie nicht den Schritt, alle Vokale wegzulassen, aber das war schon mal modern und wird auch wieder modern werden.
    Deswegen schreibt man auch die Attribute, also das Wichstigste, um eine Klasse zu verstehen, ganz nach unten in den Header.


Log in to reply