Forum: Die Delphi-IDE
by Phoenix,
1. Jul 2013
Genau darum geht es letzten Endes:
Du hast eine Funktion A die gemäß Contract einen beliebigen Wert zwischen 1 und 10 zurückliefern kann.
Du hast eine andere Funktion B, die einen Parameter hat der per Contract nur Werte zwischen 0 und 5 annehmen darf.
Wenn Du nun eine Variable aus A füllst und in B reinwirfst, dann kann Dir der Compiler eine Warnung um die Ohren hauen das dieses Ding...
Forum: Die Delphi-IDE
by Phoenix,
26. Jun 2013
Doch. Der Code der diese Variablen verändert verwendet ja auch Code Contracts. Und wenn Du dann eine Methode mit einem Contract hat, der nil als rückgabe erlaubt, und den Output in eine reinschieben willst die nil nicht erlaubt (ohne vorher if (blubb <> nil) zu machen), dann kann auch das der Compiler erkennen.
Genau das ist ja gerade die Mächtigkeit von Design by Contract. Wenn man das...
Forum: Die Delphi-IDE
by Phoenix,
26. Jun 2013
Moment. Design by Contract geht doch weit über Runtime-Checks und Assertions hinaus.
Bei echtem Design by Contract prüft Dir schon der Compiler ob die Argumente passen. Wenn Du einen Check <> nil drin hast, und die Methode mit einem hart codierten nil in einem ganz seltenen Use-case aufrufst, dann fliegt Dir das mit einer selbstgebastelten Lösung erst beim Kunden um die Ohren wenn der richtig...
