Soweit ich weiss sollte man Methoden, die nicht auf klasseninterne Variabeln und Methoden zugreifen muessen, als Funktionen implementieren. Allerdings nicht umbedingt um die Klasse schlank zu halten. Es ist halt einfach besser, dass das, was nicht internen Zugriff braucht, auch keinen hat.

Warum? Kannst du mal ein Beispiel machen um das zu zeigen?

icarus2 schrieb:

Soweit ich weiss sollte man Methoden, die nicht auf klasseninterne Variabeln und Methoden zugreifen muessen, als Funktionen implementieren. Allerdings nicht umbedingt um die Klasse schlank zu halten. Es ist halt einfach besser, dass das, was nicht internen Zugriff braucht, auch keinen hat.

Warum? Kannst du mal ein Beispiel machen um das zu zeigen?

Erklaerung und Beispiel im "Effective C++, Third Edition" von Scott Meyers, Item 23 "Prefer non-member non-friend functions to member functions".

Hast du das Buch per Zufall zur Hand? Falls nicht kann ichs sehr empfehlen.

an das kapitel erinnere ich mich

Wenn Du die Wahl hast, eine freie Funktion oder eine Methode zu schreiben, dann ist das mit der freien Funktion vielleicht gar keine schlechte Idee, da Du dann nicht versehentlich Invarianten verletzen kannst und eben nur auf public Member Zugriff hast.

Und sonst fällt mir dazu noch ein, dass in generischen Funktionen freie Funktionsaufrufe bevorzugt werden sollten. Beispiel:

template<class Container>
void show(Container const& c) {
  using std::begin;
  using std::end;
  auto       it = begin(c);
  auto const ee = end(c);
  while (it!=ee) {
    std::cout << *it << ' ';
    ++it;
  }
  std::cout << '\n';
}

Statt hier c.begin() und c.end() zu schreiben, werden freie Funktionen begin/end aufgerufen. Das ermöglicht es, dieses Funktionstemplate auch für Typen nutzbar zu machen, die solche Methoden gar nicht anbieten. Für rohe Arrays werden in diesem Beispiel dann std::begin/std::end verwendet, die für Arrays auch überladen sind. Und sonst wird noch ADL verwendet, um ggf passende begin/end Funktionen zu suchen.

ADL = argument dependent lookup

template<unsigned int N>
  BlockMatrix<N> operator * (BlockMatrix<N> const& m1, BlockMatrix<N> const& m2)
  {
    BlockMatrix<N> m;
    for (unsigned i = 0; i < N; ++i)
      for (unsigned j = 0; j < N; ++j)
        for (unsigned k = 0; k < N; ++k)
          m[i][j] += m1[k][j] * m2[i][k];
    return m;
  }

class WebBrowser
{
public:
	...
	void clearCachge();
	void clearHistroy();
	void clearCookies();
	...
};

Viele Benutzer moechten nun alles auf einmal loeschen koennen. Man koennte nun eine Methode void clearEverything implementieren in WebBrowser, die den Cache, die Histroy und die Cookies loescht:

class WebBrowser
{
public:
	...
	void clearEverything();
	...
};

Die Methode clearEverything() braucht allerdings keinen Zugriff auf Internes von WebBrowser. Man kann sie ohne weiteres mit clearHistroy(), clearCache() und clearCookies() implementieren, die oeffentlich sind.

Nach dem Grundsatz der Data Encapsulation (Datenkapselung) sollte man deshalb clearEverything auch keinen Zugriff auf die internen Dinge geben.
Deshalb ist es besser clearEverything() als als non-member function zu implementieren:

void clearBrowser(WebBrowser& wb)
{
	wb.clearCache();
	wb.clearHistory();
	wb.clearCookies();
}

Man kann sich natuerlich ueber dieses Konzept streiten. Falls du genauere und ausfuehrlichere Argumente moechtest verweise ich dich auf meine Quelle oben.