Meinungen zur idealen Schnittstelle
-
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
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?
-
Ops, jo, das meine ich. *malebenkorrigier* Danke :).
Gruß Kimmi
-
Nexus schrieb:
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
-
Dravere schrieb:
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.
-
Nexus schrieb:
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
-
Dravere schrieb:
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.
-
Ausserdem geht es darum, wie man in einem größeren Team gut mit so etwas arbeiten kann bzw. welche Variante Sinn macht. Wenn Entwickler 1 versucht, durch viele private Methoden das Ganze lesbarer zu machen, Entwickler 2 jedoch versucht, durch längere Methoden die Lösung des Problems an einem Ort zu verdichten, muß man sich ja irgendwo in der Mitte treffen. Beide Ansätze führen zum Ziel, nur wieviel von beiden Ansätzen sollte man benutzen?
Schließlich will man ja nicht, daß Entwickler 2 jedes mal alles refaktorisiert, um seinen "Stil" beizubehalten. Da wollte ich einfach mal andere Meinungen dazu hören, um einen guten Mittelweg zu finden.Gruß Kimmi
-
Ich denke mal, dass man das nicht allgemeingültig sagen kann, sondern das in dem Team, in dem man arbeitet besprechen muss. Auch wenn man sich schlussendlich dafür entscheidet etwas auf eine Art zu machen, wie es sonst niemand macht, solange die Teammitglieder sich dafür einsetzen können läufts (solange es natürlich auch Sinn macht).
-
Dem stimme ich zu. Eine endgültig perfekte Lösung gibt es nicht. Ich habe sowohl den Ansatz gesehen, daß der eine Entwickler komplett den Code umstrukturiert, um seinen Stil zu pflegen. Dummerweise kann man dann im Diff nicht mehr erkennen, wo nun die entscheidende Änderung war bzw. was sich für ein neues Feature wirklich geändert hat.
Ich kenne aber auch die andere Variante, daß man versucht, den Code weitesgehend nicht anzufassen und nur die Stellen zu modifizieren, die für die Änderung wirklich nötig sind. Nun kann gerade bei Code-Wiederholungen da gern mal eine Stelle übersehen werden.Gruß Kimmi
-
Sofern die Team-Mitglieder nicht alle total eigenwillig und stur sind, sollte man sich eigentlich auf einen mehr oder weniger einheitlichen Codestil einigen können. Zumindest, was Einrückungen, Bezeichner, Klammersetzung und solche Dinge betrifft...
Sofern das möglich ist, fände ich das sicher sinnvoller, als wenn jeder in seinem Teil seinen eigenen Stil pflegt.
