Overload function

[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.

[JamesTKirk]

Zitat von 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.

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

Gruß,
Sven

[Furtbichler]

Zitat von JamesTKirk:

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

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 von JasonDX:

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:
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 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.

[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 von Furtbichler:

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 von Furtbichler:

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 von Furtbichler:

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 von Furtbichler:

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.

[Furtbichler]

Zitat von JasonDX:

Es kommt drauf an. Oft bringen ...

Stimmt, meine Aussage war zu allgemein. Sie trifft in erster Linie auf die Overload-Thematik zu.

[JamesTKirk]

Zitat von Furtbichler:

Zitat von JamesTKirk:

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

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'?

Wo hab ich gesagt, dass mir eine kürzere Form lieber wäre? Mir ging es nur darum zu zeigen, dass auch eine C-basierte API (im Gegensatz zu einer objektorientierten API) wie die WinAPI durchaus auch lange, sprechende Namen haben kann und durchaus auch hat.

Gruß,
Sven

[Furtbichler]

Zitat von JamesTKirk:

Wo hab ich gesagt, dass mir eine kürzere Form lieber wäre? Mir ging es nur darum zu zeigen, dass auch eine C-basierte API (im Gegensatz zu einer objektorientierten API) wie die WinAPI durchaus auch lange, sprechende Namen haben kann und durchaus auch hat.

Dann war es ein Mißverständnis.