Wie geht ihr eigentlich mit privaten Variablen und Methoden in Klassen um? Ich möchte ja nicht immer, dass man gleich alles sieht, wenn man beispielsweise IntelliSense nutzt. Vor allem wenn man für alle Memberfunktionen die gleiche Namenskonvention hat, kann das schnell unübersichtlich werden - oder man muss eben alle öffentlichen Funktionen kennen.

Wie macht ihr das? Für jede kleine Klasse das Pimpl-Idiom einzusetzen finde ich übertrieben, obwohl es halt schon die Schnittstelle sauber hält. Habt ihr für private Memberfunktionen eine andere Benennung? Ich habe mir Unterstriche am Anfang überlegt, weil man die Member dann bei IntelliSense hinten stehen, aber irgendwie ist es auch nicht so schön. Für Membervariablen ein Präfix m_ oder My oder ähnlich ist ja noch okay...

Momentan sieht man bei mir von aussen eigentlich keinen wirklichen Unterschied zwischen privaten und öffentlichen Memberfunktionen (ausser dem IntelliSense-Schloss ;)). Im Header hab ich natürlich schon in eigene Sektionen unterteilt, falls man dort etwas nachschaut. Eigentlich ist das nicht tragisch, mich hätte aber gewundert, wie das andere sehen. Ist auch eine Frage des Code-Stils...

Wenn du dir Visual Assist X zulegst, dann kannst du die Methoden sogar filtern, also zum Beispiel nur alle öffentlichen Methoden anzeigen lassen. Brauche ich aber kaum.

Wieso willst du eigentlich den Rest verstecken? Was hast du zu verbergen?

Grüssli

Wie macht ihr das? Für jede kleine Klasse das Pimpl-Idiom einzusetzen finde ich übertrieben, obwohl es halt schon die Schnittstelle sauber hält.

die privaten sachen sind eh nicht teil der schnittstelle, also wozu pimpeln?

Nexus schrieb:

Wie macht ihr das? Für jede kleine Klasse das Pimpl-Idiom einzusetzen finde ich übertrieben, obwohl es halt schon die Schnittstelle sauber hält.

die privaten sachen sind eh nicht teil der schnittstelle, also wozu pimpeln?

Ich denke, dass er das wollte, damit er entscheiden kann, was sichtbar ist ( also von Seitens Intellisense). (Also nur alle public).

EDIT:
Also ich lasse es auch so. Wenn Intellisense mir etwas zeigt, dann ignorier ich das eifach. Und falls ich es doch benutze, wird mich mein Compiler schon bestrafen.

Nebenbei: Mal eine interessante Überlegung zu dem Thema.

Scheinbar aber nicht, was aber auch okay ist. Das ist ja auch eher Kosmetik. Mit grösster Wahrscheinlichkeit werde ich meinen Codestil so beibehalten...

P.S. Die Thematik des Artikels ist wirklich interessant, ich habe mal einen Teil gelesen. Ich meine, bereits die IDE an sich nimmt uns einen grossen Teil der Arbeit ab. Oder der Debugger. IntelliSense eben noch einen weiteren. Aber die Tendenz, dass man sich nichts mehr merken muss, hat schon was... Grundsätzlich finde ich diese Hilfsmittel nicht schlecht, da sie einen wirklich unterstützen können, aber es stimmt schon, man wird schneller zu deren Sklaven, als man denkt... Aber ist das nicht allgemein so? Denke man nur mal an den Computer. Was wären wir ohne ihn?

So langsam wirds philosophisch, da könnte man noch stundenlang Aufsätze schreiben...

In diesem Sinne wünsche ich allen ein gutes neues Jahr! :xmas2:

Vor allem wenn man an irgendwelchen Libraries arbeitet die dann mehrere Leute verwenden, denn übersichtlicher ist es IMO schon wenn man gleich nur die public/protected Teile sieht. Lästig wird es dagegen dann wenn man selbst Änderungen an diesen Klassen durchführt, denn man selbst bekommt die Vorschläge von IntelliSense ja dann auch nichtmehr.

Es gibt IIRC irgendeine Möglichkeit IntelliSense dazu zu bringen gewisse Dinge nicht anzuzeigen. Leider weiss ich nicht auswendig wie es geht

Ich denke einmal nicht. Aber dafür kannst du dir ja VA holen. - Dort kannst du glaube ich auch gewisse Sachen filtern.

hustbaer schrieb:

Es gibt IIRC irgendeine Möglichkeit IntelliSense dazu zu bringen gewisse Dinge nicht anzuzeigen. Leider weiss ich nicht auswendig wie es geht

Ich denke einmal nicht. Aber dafür kannst du dir ja VA holen. - Dort kannst du glaube ich auch gewisse Sachen filtern.

Irgendeine Studio Version hat zumindest mal von den MFC Klassen die privaten Member ausgeblendet. Kann aber auch sein dass das hardcoded war/ist.

Also nach dem Prinzip: möglichst nur das als Memberfunktion, was auch wirklich nötig ist?

namespace WebBrowserStuff {
    class WebBrowser {...};
    void clearBrowser(WebBrowser& wb);
    ...
}

Nexus schrieb:

Wie macht ihr das? Für jede kleine Klasse das Pimpl-Idiom einzusetzen finde ich übertrieben, obwohl es halt schon die Schnittstelle sauber hält.

die privaten sachen sind eh nicht teil der schnittstelle, also wozu pimpeln?

Das erklaere mir mal wieso ich jedesmal das gesammte Projekt neu kompilieren muss, wenn ich an einem private-Member was veraendere?

Ich eigentlich nicht. Wenn ich die Funktion möglicherweise irgendwo anders brauche kann, dann probiere ich die schon allgemeingültig zu abstrahieren, aber wenn es dann auf das hinausläuft, dass man alle Funktionen auslagert und mit einem Zeiger/Referenz auf das Objekt übergibt, dann sind wir eigentlich wieder bei C angelangt.

Hm ja, das schon.

Ich habe nur momentan in einer Klasse so etwas:

public:
    void DoSomething(MyClass& Obj);
private:
    void DoALittleBitMore(MyClass& Obj);
    void DoAnythingElse(MyClass& Obj);

Die privaten Methoden werden dann von der öffentlichen DoSomething() aufgerufen. Sie ändern aber nichts an den Membern, sondern nur an der übergebenen MyClass -Referenz. So könnte ich die beiden Memberfunktionen auch als freie Funktionen implementieren, aber irgendwie scheint es mir so besser, da sie logisch auch zur Klasse gehören...

[...]Sie ändern aber nichts an den Membern [...] So könnte ich die beiden Memberfunktionen auch als freie Funktionen implementieren[...]

übrigens schrieb:

Wie wärs, die private Methoden einfach in nen anonymen namespace zu stecken, falls sie nicht all zu viele member brauchen.

dann brauchst du dir auch keine gedanken machen, dass sie außerhalb falsch verwendet werden.
Wenn du sie als freie Funktionen machst auf die jeder zugreifen kann, dann hast du an der compilezeit ja garnix gewonnen.

volkard schrieb:

die privaten vars gehören nicht zur schnittstelle, denn die kannst du heimlich ändern, ohne den anderen programmieren eine mail schreiben zu müssen, in der du um verzeihung bittest, daß du so spät im projet was änderst und sie diese änderung berücksichtigen müssen.
was das mit dem neucompilieren zu tun hat, weiß ich nicht.

Wenn du ein größeres Projekt hast (noch größer ) und eine Klasse (z.B. Logging, Scenegraph...) die an vielen Stellen includiert wird und du änderst jetzt nur einen Parameter einer privaten Methode und darfst jetzt wieder 1000 Dateien 10 minuten lang kompilieren, dann weiß du was das mit compilezeit zu tun hat.

Okay. Mal eine etwas andere Frage: Implementiert ihr Funktionen, die die Klasse in ihrer Arbeitsweise unterstützen und möglicherweise von Memberfunktionen aufgerufen werden, aber keinen direkten Zugriff auf Membervariablen haben müssen, immer als freie Funktionen?

Also nach dem Prinzip: möglichst nur das als Memberfunktion, was auch wirklich nötig ist?

Also eigentlich: ja. Und diese freien Funktionen kommen dann nach Möglichkeit in ein eigenes Modul. Es gibt einfach prozeduale Bestandteile. Für etwas wie kreuzprodukt(vec a, vec b) macht es keinen Sinn, eine Klasse zu schreiben.

Nenne mal ein Beispiel. Also mir ist sowas eigentlich bei vernünftigem Design (wo ich sagen muss, dass das nicht immer der Fall ist ) nicht unter gekommen.

ProgChild, eigentlich mache ich das tendenziell auch so, aber vielleicht gibts da ja ein guter Grund dagegen. Bei mir habe ich irgendwie das Gefühl, es sei nicht nötig (keine Ahnung wieso).

Aber es stimmt schon, dann würde ich wahrscheinlich am Anfang der Implementierungsdatei die Deklarationen der lokalen freien Funktionen hinschreiben und anschliessend die Definitionen der Member- und freien Funktionen. Wobei ich an meinem Design generell noch ein wenig rumstudieren muss...