Wohin mit Membern

cooky451

Hi,

man kann hier leider keine Umfragen machen, aber in NadrW wollte ich den Thread dann doch nicht erstellen.
Einfache Frage: Was lest/schreibt ihr lieber?
A:

struct my_type
{
  my_type(float value)
    : value_(value)
  {}

private:
  float value_;
  my_type(my_type const&);
  my_type& operator = (my_type const&);
};

B:

class my_type
{
  float value_;

public:
  my_type(float value)
    : value_(value)
  {}

private:
  my_type(my_type const&);
  my_type& operator = (my_type const&);
};

Grundargumentation für A: Private Member haben den Leser nicht wirklich zu interessieren, das sind Implementierungsdetails. Klassenname und Namespaces geben bereits eine gute Grundidee davon, was die Klasse tut.

Grundargumentation für B: Die Strukturierung des Codes ist kein Mittel zur Kapselung im Sinne der Objektorientierung. Die Membervariablen können sehr viel schneller eine Grundidee von Aufbau und Funktionsweise der Klasse vermitteln.

also, wenn ich eine klasse anfummeln muss, wird sie idr. komplett neu gemacht! schnittstellen schau ich mir in der dokumentation an. daher ist/wär mir deine implementation wurst. wichtig ist nur, dass alle privaten auch private sind

axo, ich hab mir auch immer viel zu viele gedanken über so eine unwichtige sch.... gemacht und bin dann überhaupt nicht mehr vorwärts gekommen...

cooky451

K_K schrieb:

gemacht und bin dann überhaupt nicht mehr vorwärts gekommen..

Das ist das Problem, und deswegen wird diese Entscheidung vertrauensvoll dem Kollektiv überlassen. Das dem das allerdings völlig egal ist, passt so gar nicht.

Dobi

A lese/schreibe ich lieber.

wxSkip

Ich benutze B, aber bei mir ist das nicht so wichtig, weil ich versuche, meine Klasen klein zu halten. (Idealismus :p )

this-*gt*that

B. Meine Klassen beginnen immer mit einer private Sektion und den Membern.

DrGreenthumb

Weder A noch B. Aber alles was private ist, definitiv soweit unten wie möglich. Schlimm genug dass das überhaupt mit in den Header muss.

Dobi

Wie gehts denn noch weiter unten als bei A?

314159265358979

DrGreenthumb schrieb:

Weder A noch B. Aber alles was private ist, definitiv soweit unten wie möglich. Schlimm genug dass das überhaupt mit in den Header muss.

cooky hat das Beispiel falsch gemacht, die Member gehören natürlich ganz nach unten. Darf man dich dann also zu A zuordnen?

DrGreenthumb

314159265358979 schrieb:

DrGreenthumb schrieb:

Weder A noch B. Aber alles was private ist, definitiv soweit unten wie möglich. Schlimm genug dass das überhaupt mit in den Header muss.

cooky hat das Beispiel falsch gemacht, die Member gehören natürlich ganz nach unten. Darf man dich dann also zu A zuordnen?

weiß nicht, ich mache die Regeln nicht Mich hat bei A auch gestört das erst die Member, dann die Methoden kommen und außerdem das struct statt class.

314159265358979

Ob struct oder class ist doch grundsätzlich egal, darum gehts auch gar nicht.

Dobi

Bei class rutschen die privaten Member dadurch, dass oben ja irgendwo public steht, noch was weiter nach unten.

DrGreenthumb

314159265358979 schrieb:

Ob struct oder class ist doch grundsätzlich egal, darum gehts auch gar nicht.

die beiden Beispiele machen mir zu sehr Gebrauch von der Default-Visibility bei struct vs. class. Aber OK, zähl mich zu A

hustbaer

314159265358979 schrieb:

DrGreenthumb schrieb:

Weder A noch B. Aber alles was private ist, definitiv soweit unten wie möglich. Schlimm genug dass das überhaupt mit in den Header muss.

cooky hat das Beispiel falsch gemacht, die Member gehören natürlich ganz nach unten. Darf man dich dann also zu A zuordnen?

Meinst du so?

class Foo
{
public:
    Foo();
    void Fun();

protected:
    Foo(int, int);
    void LessFun();

private:
    int m_memba;
};

So mach ich es auf jeden Fall...

Dobi

Jo, genauso siehts bei mir auch aus.

314159265358979

@hustbaer: Ja, genau.

GorbGorb

hustbaer schrieb:

class Foo
{
public:
    Foo();
    void Fun();

protected:
    Foo(int, int);
    void LessFun();

private:
    int m_memba;
};

So macht es meines Wissens nach auch boost.

hustbaer

Also bei Boost ist mir hauptsächlich aufgefallen, dass es kaum Sachen gibt, die in den zig verschiedenen Libs so richtig konsequent überall gleich gemacht würden.

Ist aber auf jeden Fall der "Stil" den ich in "Fremdcode" am häufigsten gesehen habe.

otze

Ich Atme B.

Member haben für mich beim Codeverständnis die größte Bedeutung und bei allen leuten die A schreiben fluche ich, dass ich immer so lange scrollen muss, um irgendwas zu finden...

asc

Mir ist eigentlich vollkommen egal ob a oder b, wobei ich eher zu a tendiere. Mir ist die Schnittstelle in der Regel wesentlich wichtiger.

Ich ziehe ohnehin kurze Klassen den langen vor, so das ich die Scrollorgien die otze anspricht, auch nicht so schwer wiegen wenn man den wirklich die Implementierungsdetails benötigt (zudem sehe ich es nicht so, das Member für das Codeverständnis wichtiger sind als die Schnittstelle).