Overload function

[Furtbichler]

Zitat:

Zitat von jaenicke (Beitrag 1236898)

Das sieht dann lustig aus...

Na klar. Übertreibe maßlos, werfe noch die Returnwerte dazu, damit das schön plakativ aussieht und stelle Dich zum Schluß hin und schreie: "Ha! Recht gehabt!". Ich frage mich zwar, was das mit meinem Beitrag zu tun hat, aber blöd sieht das schon aus, wenn Du so eine Nomenklatur umsetzt, da hast Du recht. Must halt ein wenig üben, bis das sinnvoll wird.

Zitat:

Zitat von Caps (Beitrag 1236924)

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.

Jupp.

Ich schlage mich gerade mit einem UI-Framework herum, das quasi eine Methode hat: 'AddControl'. Im Formular soll ein Control hinzugefügt und an eine Property gebunden werden.

Code:

AddValue(property, label);
AddControl(property, label, width);
AddControl(property, control, label, width);
AddControl(property, control, label, size, color);
...
usw. ca 50 Varianten

Unglaublich unübersichtlich, aber eben auch praktisch. Ein Zugeständnis das Autors an -eben- Faulheit.

[JasonDX]

Zitat:

Zitat von Furtbichler (Beitrag 1236947)

Code:

AddValue(property, label);
AddControl(property, label, width);
AddControl(property, control, label, width);
AddControl(property, control, label, size, color);
...
usw. ca 50 Varianten

Unglaublich unübersichtlich, aber eben auch praktisch. Ein Zugeständnis das Autors an -eben- Faulheit.

Wobei, hier finde ich hängt es stark von den Parametern ab, die übergeben werden: Diese sollten namentlich ausreichend Sinn machen dass erkannt wird, welcher Wert übergeben wird. Dann werden zusätzliche Informationen als die zentrale Aufgabe der Methode in ihrem Namen überflüssig weil redundant. Das würde dann bei deinem Beispiel zu

Code:

addControl(property, control, label, size, color)

führen. Hingegen für 50 Varianten 50 unterschiedliche, sinnvolle Namen zu herzuleiten stelle ich mir unübersichtlicher vor. Wie würde bei deinem Beispiel guter Vorschlag aussehen?

[RWarnecke]

Wow, ich habe gar nicht gewusst, dass man das Thema so auseinander nehmen kann. Bei mir war es so, dass die THauptklasse schon da war und ich die Funktion mit TGroup nur noch hinzugefügt habe. Desweiteren unterscheiden sich die Funktionen mit TPage und TGroup nur in zwei bis drei Zeilen. Deshalb erschien es mir nur klar, dass ich für TGroup eine Overload function mache.

[Furtbichler]

Das werden hier nun mal immer Grundsatzdiskussionen.

[JamesTKirk]

Zitat:

Zitat von Daniel (Beitrag 1236903)

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.

Und die WinAPI braucht sich da auch nicht verstecken, man denke da nur an

Delphi-Quellcode:

ConvertSecurityDescriptorToStringSecurityDescriptor

und Co :mrgreen:

Gruß,
Sven

[mkinzler]

Zitat:

Zitat von Furtbichler (Beitrag 1236970)

Das werden hier nun mal immer Grundsatzdiskussionen.

Bei denen sich komischerweise immer die selben Mitglieder beteiligen. :stupid:

[Furtbichler]

Zitat:

Zitat von JamesTKirk (Beitrag 1237004)

Und die WinAPI braucht sich da auch nicht verstecken, man denke da nur an

Delphi-Quellcode:

ConvertSecurityDescriptorToStringSecurityDescriptor

und Co :mrgreen:

Es ist wohl ein riesen Unterschied, ob ich eine Methode vollständig korrekt benenne, oder Nomenklaturdadaismus à la 'Jänickes Satirekabinett' (Damit ist nur die Überzeichnung von Sebastians Antwort gemeint) veranstalte. Was wäre Dir denn lieber?
'CnvScDsc2StrScDsc'?

Zitat:

Zitat von JasonDX (Beitrag 1236951)

Hingegen für 50 Varianten 50 unterschiedliche, sinnvolle Namen zu herzuleiten stelle ich mir unübersichtlicher vor. Wie würde bei deinem Beispiel guter Vorschlag aussehen?

Korrekt und im Sinne von Clean-Code sauber wäre die Einführung einer Parameter-Klasse und eine einzige Methode:

Delphi-Quellcode:

AddControl (Property, LayoutParams);

Dann ist es aber Essig mit 'schnell ein Layout zusammentippen', denn

Delphi-Quellcode:

//statt
AddControl(MyProperty,'Name',50);
//
// schreibt man nun
//
LayoutParams := TLayoutParams.Create;
LayoutParams.Label :='Name';
LayoutParams.Width := 50;
AddControl (MyProperty,LayoutParams);

Klar, sauber, einfach. Und umständlich(er). Imho auch leichter zu testen (das wäre aber zu beweisen).

Man muss sich einfach mal dran gewöhnen (imho), das gute Softwareentwicklung mit Dahingeschreibsel (aka Bequemlichkeit) nicht mehr viel zu tun haben kann. Es kommt nur noch auf Testbarkeit, sauberes Design, klare Strukturen usw. an. Bequemlichkeit hat da keinen Platz mehr.

Gestern hat man eine Klasse in 1 Stunde erstellt. Heute dauert das 2-3 Stunden, weil die Unittests noch geschrieben werden müssen und man CC einhalten muss/sollte.

Wir räumen gerade ein Schrottprojekt auf und bei jedem Bugfix (5 Minuten) folgt Refactoring (2-4 Std), Unittests (2 Std) und Schreibkram (0.5 - 1 Std). Hobbyprogrammierer müssen das natürlich nicht so machen.

Zitat:

Zitat von mkinzler (Beitrag 1237005)

Zitat:

Zitat von Furtbichler (Beitrag 1236970)

Das werden hier nun mal immer Grundsatzdiskussionen.

Bei denen sich komischerweise immer die selben Mitglieder beteiligen. :stupid:

Unter denen sich eben auch Softwarearchitekten befinden. Oder einfach nur Programmierer, die ein Interesse an Fundamentalem haben, weil sie über den Tellerrand blicken. Beteilige dich doch einfach daran.

[mkinzler]

Zitat:

Zitat von mkinzler:
Zitat von Furtbichler:
Das werden hier nun mal immer Grundsatzdiskussionen.
Bei denen sich komischerweise immer die selben Mitglieder beteiligen.
Unter denen sich eben auch Softwarearchitekten befinden. Oder einfach nur Programmierer, die ein Interesse an Fundamentalem haben, weil sie über den Tellerrand blicken. Beteilige dich doch einfach daran.

Dafür kann man geren einen eigene Thread eröffnen, aber nicht ständig andere Threads kapern

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1237008)

Es ist wohl ein riesen Unterschied, ob ich eine Methode vollständig korrekt benenne, oder Nomenklaturdadaismus à la 'Jänickes Satirekabinett' (Damit ist nur die Überzeichnung von Sebastians Antwort gemeint) veranstalte.

Das war natürlich auch auf das Beispiel bezogen übertrieben gemeint. Bei umfangreicheren Funktionen läuft es aber trotzdem auf ähnliche Monsterbezeichner heraus.

Zitat:

Zitat von Furtbichler (Beitrag 1237008)

Dann ist es aber Essig mit 'schnell ein Layout zusammentippen', denn

Delphi-Quellcode:

//statt
AddControl(MyProperty,'Name',50);
//
// schreibt man nun
//
LayoutParams := TLayoutParams.Create;
LayoutParams.Label :='Name';
LayoutParams.Width := 50;
AddControl (MyProperty,LayoutParams);

Klar, sauber, einfach. Und umständlich(er).

Das nutzen wir auch so an einigen Stellen, auch mit Interfaces als Parameterinformation, wenn es sonst zu viele Parameter würden.

Man sieht dann besser welche Parameter eigentlich was machen. Bei guten Variablennamen sollte das ohnehin nicht so ein Problem sein, aber wenn das ein paar mehr Parameter sind, reicht das nicht mehr immer.

[JasonDX]

Zitat:

Zitat von Furtbichler (Beitrag 1237008)

Dann ist es aber Essig mit 'schnell ein Layout zusammentippen', denn

Delphi-Quellcode:

//statt
AddControl(MyProperty,'Name',50);
//
// schreibt man nun
//
LayoutParams := TLayoutParams.Create;
LayoutParams.Label :='Name';
LayoutParams.Width := 50;
AddControl (MyProperty,LayoutParams);

Klar, sauber, einfach. Und umständlich(er).

Guter Vorschlag. Mit Builder-Pattern wird das ganze sogar weniger umständlich (keine zusätzliche Variable) und leserlicher:

Code:

addControl(myProperty, LayoutParams.newBuilder()
  .setLabel('Name')
  .setWidth(50)
  .build());

Zitat:

Zitat von Furtbichler (Beitrag 1237008)

Man muss sich einfach mal dran gewöhnen (imho), das gute Softwareentwicklung mit Dahingeschreibsel (aka Bequemlichkeit) nicht mehr viel zu tun haben kann. Es kommt nur noch auf Testbarkeit, sauberes Design, klare Strukturen usw. an. Bequemlichkeit hat da keinen Platz mehr.

Es kommt draufan. Oft bringen sauberes Design und klare Strukturen auch bequemeres Coden und Testbarkeit - entsprechend fördert der Wunsch nach bequemen Coden auch sauberes Design und klarere Strukturen, und damit Testbarkeit. Also schließen sie sich nicht aus, Bequemlichkeit sollte nur nicht das Argument sein.