danke für deinen Kommentar.

Ich finde nicht, dass diese Aussage allgemeingültig ist.

Welche Aussage ist schon wirklich allgemeingültig? Gerade in der Softwareentwicklung. Deshalb mache ich es mir einfach: Statt an jede Aussage ein “selbstverständlich gibt es Ausnahmen” dran zu hängen, lasse ich meine drei obersten Daumenregeln die Ausnahmen behandeln.

Gesetzter Fall, ich hätte eine (statische) Utility-Klasse mit Methoden, die mir explizite Tasks erfüllen und für die Erfüllung ebenjener eine große Anzahl an Parametern benötigen.

Hier wäre meine Vermutung, dass die Utility-Klasse keine sein sollte. Utility-Klassen haben ihre Berechtigung, aber, wenn man sie zu viel anwendet, ist man wieder bei prozeduraler Programmierung (und eben nicht mehr objektorientiert). Der gedankliche Unterschied ist der, dass Utility-Klassen nichts “sind”, sondern nur etwas tun (siehe Daumenregeln Nr. 15 in obigem Artikel).

Aber wie gesagt: Natürlich gibt es Ausnahmen. Aber um ehrlich zu sein, denke ich, dass diese hier selten sind. Mehr als 3, maximal 4 Parameter braucht man wirklich nur sehr sehr selten.

Vielleicht könntest du deine Aussage noch mit einem Beispiel veranschaulichen, um sicherzugehen, dass ich dich nicht falsch verstanden habe.

OK, ein Beispiel:

DoSomething(42, SOME_CONSTANT, "", "",
  "HelloWorld", false, true, false, null,
  null, null, null);
Das ist jetzt zwar ein konstruiertes Beispiel, aber man sollte dennoch sehen, dass man hier kaum eine Chance hat, den Methodenaufruf zu verstehen, wenn man sich nicht Code oder Doku der Methode anguckt. Zudem kann man sehr leicht Parameter aus Versehen vertauschen oder falsch belegen, was zu sehr schwer zu findenden Fehlern führt.

Ein reales Beispiel für zu lange Parameterlisten ist CreateProcess(). Die Funktion ist richtig eklig. Besser wäre es hier, wenn es eine Prozess-Klasse gäbe, die im Konstruktor nur wenige Parameter hat und für die restlichen Infos sinnvolle Default-Werte annimmt, die man über Setter-Methoden (bzw. Properties) ändern kann. Eine start()-Methdode würde dann den Prozess starten. Das wäre viel leichter zu benutzen, viel leichter zu verstehen und weniger fehlerträchtig. Zusätzlich kann es noch ne statische Utility-Methode geben, die mir das Leben einfacher macht, wenn mir die Default-Werte ausreichen. Dann hat diese aber auch nur wenige Parameter.

Und, oh Wunder, AFAIK macht es MS jetzt genau so: Process und Process.Start().

Aber du magst wohl recht haben, es gibt bestimmt Ausnahmen. Aber keine konkreten, die mir jetzt einfallen würden. Wenn du eine weißt, würde sie mich interessieren.

Gruß

Christian

zu “Lange Parameterlisten sind schwer lesbar und zeugen von schlechtem Design.”

Ich finde nicht, dass diese Aussage allgemeingültig ist. Gesetzter Fall, ich hätte eine (statische) Utility-Klasse mit Methoden, die mir explizite Tasks erfüllen und für die Erfüllung ebenjener eine große Anzahl an Parametern benötigen. Wie sollte man das design-technisch besser lösen als mittels einer langen Parameterliste? Man könnte das Ergebnis natürlich ebenso bekommen, indem man mehrere Methoden hintereinanderschaltet und die Rückgabewerte immer weiterreicht. Ich finde, dass dieses Design eher die Bindung vermindert und die Kopplung erhöht.

Vielleicht könntest du deine Aussage noch mit einem Beispiel veranschaulichen, um sicherzugehen, dass ich dich nicht falsch verstanden habe.

Grüße
Jan