Konkret im Code heißt das:
Statt

class foo
{
public:
  foo();
  ~foo();
  void bereiteVor( int startwert );
  void bereiteNach();
  void machDasWofürIchDabin();
};

eher

class foo
{
public:
  foo(  int startwert );
  ~foo();
  void machDasWofürIchDabin();

private:
  void bereiteVor();
  void bereiteNach();
};

Dazu benutze ich gern auch kurze Methoden, um den Code lesbarer zu gestalten. Also statt:

void foo::bar( int i, int y, bar *pPtr )
{
  if ( i< 1 && y > 2 && pPtr )
    // sortiere
...
}
[cpp]

eher so was:

[cpp]
// private
bool foo:BedFürSortIstErfüllt( int i, int y, bar *pPtr )
{
  if ( i< 1 && y > 2 && pPtr )
    return true;
  return false; 
}

void foo::bar( int i, int y, bar *pPtr )
{
  if ( BedFürSortIstErfüllt() )
    // sotiere
...
}

Nachteil des Ganzen: Viele private Methoden, dementsprechend Header mit einer Unmenge an privaten Methoden. Dafür treten aber kaum Code-Wiederholungen auf.

Wie geht ihr vor, was sind eure Erfahrungen?

Gruß Kimmi

Nachteil des Ganzen: Viele private Methoden, dementsprechend Header mit einer Unmenge an privaten Methoden.

Wenn dich das stoert, dann verwende das pimpl-Idiom.

Gruß Kimmi

Grundsätzlich würde ich aber sagen, das Aufsplitten in kleine Funktionen lohnt sich vor allem, wenn diese an mehreren Stellen aufgerufen werden (und somit Codeduplizierung verhindern) oder wenn dadurch die Übersichtlichkeit gesteigert wird. Man kann es aber auch übertreiben, ich persönlich beliesse es zum Beispiel bei einer Funktion fürs Sortieren, ausser es ist ein sehr komplizierter Algorithmus im Spiel, der noch etliche Nebeneffekte oder ähnliches bewirkt.

Falls dir die privaten Memberfunktionen zu viel werden, kannst du dich mal nach dem Handle-Body-Idiom (Pimpl) umschauen. Da kann man die Implementierung in eine andere Klasse verlagern, wodurch Abhängigkeiten verringert werden.

P.S. Du meinst doch sicher "ideale Schnittstelle", oder?

Gruß Kimmi

Das geht wieder in Richtung Code-Stil, somit kann nicht von einem einzig wahren Weg die Rede sein. Hoffe, dass dieser Thread nicht in einen Flamewar ausartet. :p

*kopfnick kopfnick*

Nexus schrieb:

Grundsätzlich würde ich aber sagen, das Aufsplitten in kleine Funktionen lohnt sich vor allem, wenn diese an mehreren Stellen aufgerufen werden (und somit Codeduplizierung verhindern) oder wenn dadurch die Übersichtlichkeit gesteigert wird. Man kann es aber auch übertreiben, ich persönlich beliesse es zum Beispiel bei einer Funktion fürs Sortieren, ausser es ist ein sehr komplizierter Algorithmus im Spiel, der noch etliche Nebeneffekte oder ähnliches bewirkt.

*kopfnick kopfnick*
Und ich denke die Schwierigkeit am Ende ist es, dass man das Mittelmass findet. Dieses ist nicht nur jedes mal sehr anders, sondern auch äusserst subjektiv.

Nexus schrieb:

Falls dir die privaten Memberfunktionen zu viel werden, kannst du dich mal nach dem Handle-Body-Idiom (Pimpl) umschauen. Da kann man die Implementierung in eine andere Klasse verlagern, wodurch Abhängigkeiten verringert werden.

Shade Of Mine schrieb:

Wenn dich das stoert, dann verwende das pimpl-Idiom.

Die Frage geht an euch zwei:
Ist das schlussendlich nicht einfach nur eine Verlagerung des Problems? Also jetzt in diesem speziellen Falle mit den zu vielen privaten Methoden.

Wenn schon würde ich eher empfehlen, dass man die Funktion der Klasse weiter aufsplittet, wenn dies möglich ist.

Grüssli

Die Frage geht an euch zwei:
Ist das schlussendlich nicht einfach nur eine Verlagerung des Problems? Also jetzt in diesem speziellen Falle mit den zu vielen privaten Methoden.

Es kommt halt drauf an. Viele private Memberfunktionen sind ja an sich nicht schlimm, mühsam wird es, wenn man oft Änderungen durchführt und dadurch immer alle abhängigen Module neu kompilieren muss. Bei vielen kleinen Funktionen ist die Tendenz für Änderungen der Deklarationen auch höher.

Und ich weiss auch nicht, inwiefern sich der Threadersteller nur an dem reinen Gedanken gestört hat, viele private Methoden in der Klasse zu haben, und nicht an den effektiven Auswirkungen...

Dravere schrieb:

Wenn schon würde ich eher empfehlen, dass man die Funktion der Klasse weiter aufsplittet, wenn dies möglich ist.

Ja, wobei man hier auch aufpassen muss. Möglich ist eine weitere Kapselung sehr oft - fraglich ist eher, ob es einem einen Vorteil bringt. Eine Klasse, die eine bestimmte Funktionalität hat, sollte man nicht künstlich aufzutrennen versuchen.

Was auch dazukommt und mir erst jetzt aufgefallen ist: Funktionen, die nicht direkt auf Member der Klasse zugreifen und keine strenge Bindung zur Klasse haben, sollten wenn möglich als freie Funktion implementiert werden. Das gilt zum Beispiel für das Sortierkriterium im Codebeispiel des Threaderstellers. Auf diese Weise kann die Anzahl Memberfunktionen ebenfalls reduziert werden.

Viele private Memberfunktionen sind ja an sich nicht schlimm, ...

Kommt drauf an, wieviele es sind. Wenn er 200 Stück hat, dann empfinde ich dies als VIEL ZU VIEL

Und wenn es eben viel zu viele sind, dann kann ich auch das folgende verstehen:

Nexus schrieb:

Und ich weiss auch nicht, inwiefern sich der Threadersteller nur an dem reinen Gedanken gestört hat, viele private Methoden in der Klasse zu haben, und nicht an den effektiven Auswirkungen...

Es geht nicht um die Auswirkungen, sondern die Übersicht und Wartbarkeit.
Deshalb meinte ich eben auch, dass ihr mit dem Pimpl-Idiom grundsätzlich das Problem nur verschiebt.

Grüssli

Es geht nicht um die Auswirkungen, sondern die Übersicht und Wartbarkeit.
Deshalb meinte ich eben auch, dass ihr mit dem Pimpl-Idiom grundsätzlich das Problem nur verschiebt.

Du hast insofern Recht, als die Klasse grundsätzlich fragwürdig ist, sobald einem die Anzahl Memberfunktionen zu viel wird. Da ist abhängig vom Fall eine der anderen Vorgehensweisen besser geeignet (sofern sinnvoll), hier nochmals zusammengefasst:

• Zusammenfassung von Funktionen
• Aufteilung der Klasse
• Erstellung freier Funktionen (geht auch lokal in der CPP-Datei, ohne Deklaration im Header - so sieht man von aussen gar nichts)

Aber je nach Anwendung kann Pimpl schon die Übersicht oder Wartbarkeit erhöhen. Vor allem, wenn die Schnittstellenfunktionen mehr oder weniger gleich bleiben, während deren aufgerufene private Methoden häufig geändert werden.

Gruß Kimmi

Gruß Kimmi

Sofern das möglich ist, fände ich das sicher sinnvoller, als wenn jeder in seinem Teil seinen eigenen Stil pflegt.