Hilfsfunktion in Klasse oder außerhalb?



  • Guten Tag!

    Ich habe in einer Klasse eine Methode method() und die ruft jetzt mehrere Hilfsmethoden auf, die ich nur in method() brauche. Diese Hilfsmethoden benutzen KEINE member der Klasse und arbeiten nur auf den Argumenten.
    Sollte ich solche Hilfsmethoden dann aus der Klasse rausziehen und zu freien Funktionen machen? Oder besser als Methode lassen?



  • Rausziehen und in einen anonymen Namespace in der cpp packen.
    Danm kannst du sie ändern ohne das Interface der Klasse anzupacken.



  • Hm.
    Ich würde die Funktionen persönlich drinn lassen, wenn wirklich keine andere Klasse die Funktion braucht.



  • Kein anderer wird diese Funktion benutzen. Ich tendiere auch dazu sie drinnen zu lassen.



  • chp++ schrieb:

    Hm.
    Ich würde die Funktionen persönlich drinn lassen, wenn wirklich keine andere Klasse die Funktion braucht.

    Begründung?



  • manni66 schrieb:

    chp++ schrieb:

    Hm.
    Ich würde die Funktionen persönlich drinn lassen, wenn wirklich keine andere Klasse die Funktion braucht.

    Begründung?

    Ich persönlich mag es, wenn ich die Funktionen die eine Klasse benötigt gleich im HPP sehe.

    Mich persönlich würde es irritieren in einem cpp file zu einer Klasse Funktionen zu sehen die nicht im Interface zu sehen sind.

    Außerdem ist die Isolierung auch ein Trugschluss, denn das Verhalten der Klasse kann sich ja ändern, bzw. muss trotzdem getestet werden, wenn man die helper functions ändert.
    Nur muss man, wenn sie nicht private deklariert wurden, dann auch noch rausfinden ob irgendjemand anderes vielleicht über die Funktion gestolpert ist und sie ebenfalls verwendet. (Warum auch immer)

    Ist vielleicht einfach eine Geschmackssache aber bei mir stehen in cpp Files nur Sachen die zur jeweiligen Klasse gehören und auch im HPP auftauchen.

    Ich habe in meinem HPP Files immer eine Dreiteilung:

    1. C/M/D-Tor

    2. normale methods

    3. helper function/methods



  • Isolierung schrieb:

    Rausziehen und in einen anonymen Namespace in der cpp packen.

    +1

    @chp++/Uliaa
    Wozu das Header-File mit Hilfsfunktionen zuspammen?
    Wenn keine Member-Variablen gebraucht werden, dann ist es schonmal ne freie Funktion. Und wenn sie "public" keinen Sinn macht, dann wandert sie ins .cpp File in einen anonymous namespace.



  • chp++ schrieb:

    Ich persönlich mag es, wenn ich die Funktionen die eine Klasse benötigt gleich im HPP sehe.

    Wenn die Funktionen doch aber keinen "nicht-public" Zugriff auf die Klasse brauchen, und auch nicht zum Interface gehören...
    ...dann sind sie ja wohl ziemlich klar ein Implementierungsdetail.
    Wieso sollte man das im Headerfile sehen sollen/wollen?

    Mal angenommen es gäbe keine strlen Funktion, und man würde sich eine String-Klasse basteln, die halt auch C-Strings entgegennehmen können soll...
    Würdest du dann die strlen Funktion als private static mit in die String-Klasse reinnehmen?



  • chp++ schrieb:

    Ich persönlich mag es, wenn ich die Funktionen die eine Klasse benötigt gleich im HPP sehe.

    Mich persönlich würde es irritieren in einem cpp file zu einer Klasse Funktionen zu sehen die nicht im Interface zu sehen sind.

    Das ist doch gerde der Sinn einer Schnittstelle: was zum Kontakt mit der Aussenwelt benötigt wird und nur das wird hier spezifiziert. Die Implementierungsdetails gehen niemanden etwas an.

    Außerdem ist die Isolierung auch ein Trugschluss, denn das Verhalten der Klasse kann sich ja ändern, bzw. muss trotzdem getestet werden, wenn man die helper functions ändert.

    Darum geht es nicht. Du musst nich alles neu übersetzen, nur weil eine Hilfsfunktion jetzt eine Parameter mehr benötigt. Siehe auch pimpl.

    Nur muss man, wenn sie nicht private deklariert wurden, dann auch noch rausfinden ob irgendjemand anderes vielleicht über die Funktion gestolpert ist und sie ebenfalls verwendet. (Warum auch immer)

    Wenn die Funktionen in einem anonymen namespace stehen, können sie genauso gut oder schlecht verwendet werden, wie als private Member. Sollte allerdings tatsächlich woanders genau die gleich Funktionalität benötigt werden, kann man sie leicht aus dem Modul herrausziehen, ohne alles neu übersetzen zu müssen. Wiederverwendung strebt man übrigens an.



  • Also mich interessiert dieses Thema ja auch schon etwas länger 🙂

    manni66 schrieb:

    Das ist doch gerde der Sinn einer Schnittstelle: was zum Kontakt mit der Aussenwelt benötigt wird und nur das wird hier spezifiziert. Die Implementierungsdetails gehen niemanden etwas an.

    Aber das lässt sich so doch eh nicht umsetzen? Weil private Methoden muss ich ja sowieso mit in das "Interface" aufnehmen, also ist jemand der sich nur den Header (und damit die Schnittstelle) anschaut sowieso immer auch mit Implementierungsdetails konfrontiert.

    manni66 schrieb:

    Wenn die Funktionen in einem anonymen namespace stehen, können sie genauso gut oder schlecht verwendet werden, wie als private Member.

    Das mit dem unnamed namespace geht aber leider nur bei "normalen" Klassen, wenn templates im Spiel sind geht das ja nichtmehr. Deswegen nehm ich das aus Konsitenzgründen meistens auch die Variante mit privater Methode.

    Wenn man aber eh "gar keine Member" der Klasse braucht (wie vom TE ja geschrieben) dann ist so eine Hilfsfunktion ja eh völlig unabhängig von der eigentlichen Klasse und hat mMn auch nichts in der .cpp Datei einer solchen zu suchen.

    hustbaer schrieb:

    Mal angenommen es gäbe keine strlen Funktion, und man würde sich eine String-Klasse basteln, die halt auch C-Strings entgegennehmen können soll...
    Würdest du dann die strlen Funktion als private static mit in die String-Klasse reinnehmen?

    Also in dem Fall würde ich erstmal die strlen Funktion als freie Funktion implementieren und (unabhängig von meiner eigenen String Klasse) in einem eigenen namespace ( str_utils oder so) zur Verfügung stellen. Würde jetzt für mein Empfinden mehr Sinn machen als die in einem unnamed namespace zu verstecken.



  • happystudent schrieb:

    manni66 schrieb:

    Das ist doch gerde der Sinn einer Schnittstelle: was zum Kontakt mit der Aussenwelt benötigt wird und nur das wird hier spezifiziert. Die Implementierungsdetails gehen niemanden etwas an.

    Aber das lässt sich so doch eh nicht umsetzen? Weil private Methoden muss ich ja sowieso mit in das "Interface" aufnehmen, also ist jemand der sich nur den Header (und damit die Schnittstelle) anschaut sowieso immer auch mit Implementierungsdetails konfrontiert.

    Wat mutt dat mutt.
    Siehe aber auch pimpl und abstrakte Klasse.

    manni66 schrieb:

    Wenn die Funktionen in einem anonymen namespace stehen, können sie genauso gut oder schlecht verwendet werden, wie als private Member.

    Das mit dem unnamed namespace geht aber leider nur bei "normalen" Klassen, wenn templates im Spiel sind geht das ja nichtmehr. Deswegen nehm ich das aus Konsitenzgründen meistens auch die Variante mit privater Methode.

    Und implementierst du aus Konsistenzgründen dann auch alle Funktionen im Header, wenn es kein Template ist?

    Wenn man aber eh "gar keine Member" der Klasse braucht (wie vom TE ja geschrieben) dann ist so eine Hilfsfunktion ja eh völlig unabhängig von der eigentlichen Klasse und hat mMn auch nichts in der .cpp Datei einer solchen zu suchen.

    1. Es ist ein Impelemntierungsdetail der Klasse
    2. Du sagst, es gehört nicht ins cpp und machst sie dann zu privaten Memberfunktionen? Irgendwie nicht logisch



  • manni66 schrieb:

    Wat mutt dat mutt.
    Siehe aber auch pimpl und abstrakte Klasse.

    Selbst mit pimpl hab ich private Implementierungsdetails im Header, etwa den namensgebenden Pointer. Interessiert mich ja auch nicht dass da jetzt jemand das pimpl idiom benutzt hat, ich will ja einfach nur die Klasse benutzen. Ein Header ist mMn einfach keine reine Schnittstellen Beschreibung, da man immer irgendwelche details darin haben wird die man für die eigentliche Verwendung nicht braucht.

    manni66 schrieb:

    Und implementierst du aus Konsistenzgründen dann auch alle Funktionen im Header, wenn es kein Template ist?

    Nein, ich bin allgemein etwas unzufrieden mit der Situation dass Klassen Templates und normale Klassen sich da unterscheiden. Aber damit muss man wohl leben 😃

    manni66 schrieb:

    1. Es ist ein Impelemntierungsdetail der Klasse
    2. Du sagst, es gehört nicht ins cpp und machst sie dann zu privaten Memberfunktionen? Irgendwie nicht logisch

    Nein, ich meinte jetzt auf das Beispiel bezogen dass die Funktion völlig unabhängig vom eigentlichen Objekt arbeitet, also so wie das strlen Beispiel. So eine Funktion würde ich entweder direkt in einem "normalen" namespace für alle zugänglich anbieten oder halt in einem "detail" namespace "verstecken".

    Wenn die Funktion auf dem eigentlichen Objekt arbeitet und eine Unter/Hilfsfunktion der Klasse ist braucht man eh fast immer private Zugriff, also braucht man eh die private Methode.


Log in to reply