Overload function

[himitsu]

Methoden mit der selben Funktion heißen so auch gleich?

[Furtbichler]

Zitat von himitsu:

Methoden mit der selben Funktion heißen so auch gleich?

Sie können nicht die selbe Funktion haben, denn die Parameter sind nicht gleich. Sie machen im Wesen das gleiche, daher wird der Name auch ähnlich sein Die eine postet (was eigentlich?), die nächste postet eine Gruppe und die dritte postet eine Page.

Überladene Funktionen sind überflüssig und ein Zugeständnis an die Faulheit der Programmierer (die sie benutzen). Ich verstehe die scheinbare Ästhetik dahinter, aber es ist nicht (imho) 100% clean.

[BUG]

Es mindestens gibt eine Sache, die ohne überladene Funktionen nicht geht: Das nachträgliche Hinzufügen von Spezialisierungen ohne den aufrufenden Code anzufassen.
Adhoc würde ich behaupten, dass in einigen Fällen gut mit dem Visitor-Pattern zusammen geht.

Ein mögliches Problem in dem Code würde ich an einer anderen Stelle vermuten: Warum ruft die Funktion mit den 3 Parametern überhaupt eine der beiden anderen auf? Vielleicht es günstiger, wenn die gemeinsam genutzte Funktionalität in eine einzelne Methode auszulagern, insbesondere wenn sich die Methoden für Group und Page so wenig unterscheiden, das du nicht mal darüber nachgedacht hast, welche von den beiden du aufrufen möchtest.

[himitsu]

OK, man könnte es natürlich auch so machen:
function Post(const Msg, Link, Image: string; PageOrGroup: TObject=nil): string;

Durch die Überladung hat man einmal das CodeInsight, sowie Codevervollständigung als Hilfe, um darübber die möglichen Parameter zu sehen.
OK, das kann man jetzt auch über DocInsight bekommen.

Aber dadurch hat man immernoch die Typprüfung des Compilers und muß nicht erst nachträglich, also zur Laufzeit, den Typ manuell prüfen.



Allerdings hätte ich es hier anders gelöst, da die 2-Parameter-Variante eh nur eine Weiterleitung ist.

Delphi-Quellcode:

    function Post(const Msg, Link, Image: string; Page: TPage=nil): string; overload;
    function Post(const Msg, Link, Image: string; Group: TGroup): string; overload;

Denn so sieht man auch gleich was aufgerufen wird, wenn man da "nichts" übgibt.

[jaenicke]

Zitat von Furtbichler:

Überladene Funktionen sind überflüssig und ein Zugeständnis an die Faulheit der Programmierer (die sie benutzen).

Mit Faulheit hat das rein gar nichts zu tun. Es macht nur keinen Sinn sich krampfhaft unterschiedliche Namen ausdenken zu müssen und umgekehrt immer die passende zu suchen, wenn die Funktionen im Grunde alle doch das gleiche machen.

Bei überladenen Operatoren sehe ich z.B. auch keinen Sinn da noch zusätzliche Namen hinzuzufügen, damit die nicht alle implicit oder explicit heißen.

[Furtbichler]

Zitat von jaenicke:

Mit Faulheit hat das rein gar nichts zu tun. Es macht nur keinen Sinn sich krampfhaft unterschiedliche Namen ausdenken zu müssen und umgekehrt immer die passende zu suchen, wenn die Funktionen im Grunde alle doch das gleiche machen.

Genau das meine ich mit 'Faulheit'('Macht keinen Sinn..krampfhaft..zu müssen'), danke für die Erklärung. q.e.d.

Mit der von mir beschriebenen Nomenklatur ist das im Übrigen nicht 'krampfhaft', sondern intuitiv und nach Schema 'F' (eine sehr wichtige Eigenschaft von Nomenklaturen). Die Methodengruppe wird ein 'Post' machen. Das biete ich für die Parameter 'TGroup' und 'TPage' an. Hmm, wie würden die Methoden dann heißen? Also ich weiß ja nicht, wie locker Du so bist, aber ich verkrampfe hier noch nicht.

Außerdem ist es mir neu, das man in Zeiten des 'Code Proposals' großartig suchen muss, zumal die Namen ja alle untereinanderstehen. Was machst Du denn bei einer überladenen Funktion? Du suchst Dir 'Post' aus und hoffst, das der 4.Parameter passend überladen wurde, nachdem Du die ersten drei eingetippt hast (ich arbeite nicht mehr mit Delphi, bei VS ist das so und nervt). Bei meiner Variante siehst Du das aber *sofort*. So schlecht kann meine Idee dann ja gar nicht sein, oder?

Ich weiß ja, das es bequem ist und einer gewissen Ästhetik nicht entbehrt, aber es ist eben nicht konsequent durchgezogenes OOP.

Was macht 'PostGroup'? Es wird die 'TGroup' irgendwie konvertieren und 'posten'. Und 'PostPage'? Die wird eine 'TPage' irgendwie konvertieren und auch posten. In jedem Fall machen die Methoden zu viel, nämlich zwei Dinge (Konvertieren + Posten). Ergo sollte man das Konvertieren vom 'Posten' trennen. Im konkreten Fall kann das natürlich intern anders sein, im Wesen wäre das aber vermutlich so.

Ich kenne natürlich Fälle, wo Überladung wirklich praktisch ist: Bei der Arbeit mit Frameworks (riesiger Funktionsumfang, einfach zu verwenden). Aber es ist eben nur praktisch (wogegen wirklich nichts zu sagen ist). Sauber (=Clean Code) ist es in meinen Augen jedenfalls nicht. Aber ob man immer 100% Clean programmieren möchte oder auch mal fünfe grade sein lassen will, muss jeder selbst entscheiden.

[jaenicke]

Zitat von Furtbichler:

Mit der von mir beschriebenen Nomenklatur ist das im Übrigen nicht 'krampfhaft', sondern intuitiv und nach Schema 'F' (eine sehr wichtige Eigenschaft von Nomenklaturen). Die Methodengruppe wird ein 'Post' machen. Das biete ich für die Parameter 'TGroup' und 'TPage' an. Hmm, wie würden die Methoden dann heißen? Also ich weiß ja nicht, wie locker Du so bist, aber ich verkrampfe hier noch nicht.

Das sieht dann lustig aus, wenn ein Framework ein paar mehr Möglichkeiten hat...

Delphi-Quellcode:

Contents := PostByPostDataFileReturnString(Url, PostDataFileName);
if PostByPostDataStreamSaveInFileReturnSuccess(Url, PostDataStream, ResultFileName) then
  ...

Das nenne ich unsauber.

[Daniel]

Ein gewisses Augenmaß sollte man beim Design seiner Methoden nicht verlieren. Ein bekanntes SDK, welches mit langen, sprechenden Methoden-Namen arbeitet, ist z.B. das von iOS - gerade weil ObjectiveC das Überladen gar nicht vorsieht. Geht alles, und gar nicht mal schlecht.

[Stevie]

Zitat von jaenicke:

Zitat von Furtbichler:

Mit der von mir beschriebenen Nomenklatur ist das im Übrigen nicht 'krampfhaft', sondern intuitiv und nach Schema 'F' (eine sehr wichtige Eigenschaft von Nomenklaturen). Die Methodengruppe wird ein 'Post' machen. Das biete ich für die Parameter 'TGroup' und 'TPage' an. Hmm, wie würden die Methoden dann heißen? Also ich weiß ja nicht, wie locker Du so bist, aber ich verkrampfe hier noch nicht.

Das sieht dann lustig aus, wenn ein Framework ein paar mehr Möglichkeiten hat...

Delphi-Quellcode:

Contents := PostByPostDataFileReturnString(Url, PostDataFileName);
if PostByPostDataStreamSaveInFileReturnSuccess(Url, PostDataStream, ResultFileName) then
  ...

Das nenne ich unsauber.

Das Beispiel verfehlt leider die zitierte Aussage.
Du vermischst hier Überladung aufgrund unterschiedlicher ÜbergabeParameter und Methoden, die unterschiedliche Rückgabewerte haben.
Die Methode deutet schon anhand des Namens an, dass sie mehr als eine Sache macht. Und dann nimmst du auch noch das Result in den Namen auf.

Besser:

Delphi-Quellcode:

Contents := PostByFileName(Url, PostDataFileName);
if TryPostByStream(Url, PostDataStream) and SaveToFile(PostDataStream, ResultFileName) then
  ...

oder

Delphi-Quellcode:

Contents := PostByFileName(Url, PostDataFileName);
if SaveToFile(PostDataStream, ResultFileName) then
  if TryPostByFileName(Url, ResultFileName) then
  ...

Ich würd das sauber nennen.

[Caps]

Nun, die Frage ist doch, welche Probleme das Überladen aufwerfen könnte (Verständnisprobleme beim Lesen des Quellcodes/ Ambiguitäten).
Mir ist Überladen ganz angenehm (wegen meiner eigene Faulheit natürlich ). Wenn keine Probleme entstehen, dann ist es halt syntaktischer Zucker.

lg Caps