Code Contracts machen die Validierung leicht und sorgfältig

Code Contracts ermöglichen es, Validierungslogik in seine Methoden und Klassen einzubinden, ohne viele if/then-Anweisungen schreiben zu müssen. Außerdem bieten Code Contracts die Möglichkeit, diese Validierung sowohl während der Kompilierung als auch zur Laufzeit durchzuführen, was traditioneller Validierungscode nicht schafft.

Was macht Code Contracts so hilfreich für die Validierung? Bislang erforderte Validierungscode vom Entwickler das Schreiben einer großen Anzahl von if/then-Anweisungen. An sich stellt dies kein Problem dar, denn solche Anweisungen sind nicht schwer zu schreiben. Das Problem ist die dahinterstehende Logik, die auf den ersten Blick nicht sofort ersichtlich wird. Es ist schwierig, zwischen Validierungscode und dem eigentlichen Code zu unterscheiden.

Obwohl der Code nicht schwer ist, muss er geschrieben und mühsam gepflegt werden. Von daher wird er nur selten aktualisiert oder sogar ganz vergessen, wenn sich die Geschäftslogik ändert. Mit dem Validierungscode etwas anderes zu tun, als Exceptions (Ausnahmefehler) auszulösen, erfordert viel Arbeit. Daher begnügen sich die meisten Entwickler genau damit, und der Aufrufer registriert diese einfach oder protokolliert sie wie jede andere Fehlermeldung auch. Schließlich ist dieser Code für den Compiler nicht von anderem Code zu unterscheiden, was eine statische Analyse oder spezielle Unit-Tests eher unwahrscheinlich macht.

Zur Verdeutlichung stelle man sich eine Methode mit der folgenden Signatur vor:

Die Geschäftslogik zur Validierung dieser Methode ist, dass 0 5 ist, und Input3 den Wert 500 enthalten muss. Der folgende Beispielcode A zeigt die Validierung hierfür.

Beispielcode A

Das ist fürchterlich viel Code für eine so kleine Aufgabe.

Nun kommt noch eine weitere Bedingung hinzu: Der Rückgabewert dieser Funktion darf nicht negativ sein. Dies erfordert einen weiteren if/then-Block, der Exceptions auslöst (siehe Beispielcode B).

Beispielcode B

Es gibt einige Klassen, die feststellen können müssen, ob sie „gültig“ oder bereit sind. Häufig schreibt der Entwickler eine IsValid()-Methode, um die Validierung durchzuführen, und ruft diese am Ende jeder Methode auf, die den Status der Klasse ändert. Dies wird schnell zu einer lästigen Pflicht, und der Aufruf leicht vergessen.