Offenes Array oder Set als Parameter

[Der schöne Günther]

Erweiterbar ist genau das was Rufo vorgeschlagen hat (wobei ich einen Record als typisches POD und keine Klasse genommen hätte)*. Packe die Daten die deine Methode zum Arbeiten braucht in eine Struktur und übergib sie ihr. Braucht die Methode eines Tages mehr Daten, passt du nur diese Klasse/Record an und nicht alle hundert Aufrufe im Programm.

Das mit dem Set habe ich jetzt war verstanden, finde es trotzdem nicht gut. Jedes mal wenn etwas neues hinzu kommt musst du deinen TBlankPos-Typ anfassen.
Packst du diese Absolutwerte für ein TRect wirklich direkt in den Quellcode? Ich finde, dadurch gewinnt man nicht viel. Wenn du es zur Laufzeit machst kann dein Benutzer das z.B. auch aus einer selbst anpassbaren Datei laden und muss dich nicht jedes mal nerven wenn er es ändern will.


* Irgendeine Berühmtheit hat mal gesagt zwei Methodenparameter gehen grade noch, drei seien zu viel (Ich glaube es war Martin Fowler).

[mjustin]

Zitat von Der schöne Günther:

* Irgendeine Berühmtheit hat mal gesagt zwei Methodenparameter gehen grade noch, drei seien zu viel (Ich glaube es war Martin Fowler).

Martin C. Fowler, "Clean Code", S. 73:

Zitat:

Funktionen, die drei Argumente übernehmen, sind erheblich schwerer zu verstehen als Dyaden. Die Probleme (...) werden mehr als verdoppelt.

Und auf Seite 74 werden die von Sir Rufo vorgeschlagenen "Argument Objekte" beschrieben. Sie sind keine Schummelei

[TRomano]

Ich bekomme immer wieder bei Refactoring das Grausen, wenn ich functions/procedures mit 15-20 Parametern sehe und diese in den Sourcen eines Projektes auch hunderte Male aufgerufen werden. Das ist eine Orgie, wenn mal ein Parameter geändert/zugefügt/gelöscht wird ...
Ich bevorzuge auch records als Parameter, wenn es mehr als drei Parameter werden sollen.