- Redundanzen sind doof.
- Variablen, die eigentlich lokal deklariert sein könnten, aber als Attribut in der Klasse stehen, sind eklig.
- Variablen, die als String deklariert werden, obwohl sie Integers, enums oder gar Objekte sein könnten, sind scheußlich.
- Objekte, die erzeugt, aber nicht verwendet werden, sind sinnfrei.
- Magic Values sind böse.
- Konstanten sind nicht böse. Man darf sie ruhig verwenden.
- Bezeichner, die nicht das kommunizieren, was sie bezeichnen, sind nervig.
- Bezeichner, die absolut gar nichts aussagen, sind <hier stark negativ besetztes Adjektiv einsetzen>
- Lange Parameterlisten sind schwer lesbar und zeugen von schlechtem Design.
- Wenn ich bei Methoden Parameter abzählen muss, um zu gucken, ob ich einen vertauscht hab, ist da etwas faul.
- Wenn ich Parameter mit Dummy-Werten füllen muss, läuft da was schief.
- Magic Values sind böse.
- Objektorientiert programmiert man nicht, wenn man irgendwie Objekte verwendet, sondern, indem man objektorientiert denkt.
- Objekte sind etwas anderes als Tabellen. Ja, wirklich.
if (a == null) return null; else return a;ist das selbe wiereturn a;- REST ist jetzt nicht furchtbar kompliziert. Aber den Unterschied zwischen Ressourcen und Verben sollte man schon verstanden haben.
- Passwörter speichert man nicht im Klartext.
- SQL Injection kann man verhindern
- Magic Values sind böse.
- Eine Klasse mit über 800 LOC ist vermutlich eher weniger „simple“.
- NullPointerExceptions sollte man nicht fangen, sondern verhindern.
- Obsoleten Code kann man entfernen. Man benutzt dazu wahlweise [DEL] oder [Backspace].
- Code einheitlich einzurücken, tut nicht weh. Zumal einem die IDE dabei helfen kann.
- Fehlerbehandlung heißt nicht, im Fehlerfall nen Stacktrace auszugeben und dann einfach weiter zu machen, als wär nichts gewesen.
- Hab ich schon erwähnt, dass Magic Values böse sind?
- …
- Meine Zehnägel tun weh.
Wollt ich nur mal loswerden…
Permalink
Hi 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
Permalink
Hallo Jan,
danke für deinen Kommentar.
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.
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.
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