Verträge für Delphi / Design by Contract

[sx2008]

Zitat von jaenicke:

In Delphi selbst gibt es dafür nichts

Das ist wirklich sehr schade weil design by contract würde sehr gut zu dem Konzept einer stark typisierten Sprache passen.
Delphi hat in den letzten 12 Jahren leider viel an Boden verloren.
Also Emba: baut das ein, Pre-/Postconditions und Invariants wären doch relativ einfach unzusetzen.

[jaenicke]

Ich sehe allerdings nicht viele Vorteile gegenüber rein eigenem Code. Denn angeben muss man das so oder so und ob man die Bedingungen nun komplett prüft oder nur die Bedingungen hinschreibt... Eine Funktion wie Assert für diese Fälle kann man auch selbst schreiben, die das Ergebnis prüft.

Invariants lassen sich natürlich nicht ganz so einfach umsetzen, weil man deren Prüfung manuell in jede Methode einer Klasse packen müsste...

[Phoenix]

Zitat von jaenicke:

Ich sehe allerdings nicht viele Vorteile gegenüber rein eigenem Code. Denn angeben muss man das so oder so und ob man die Bedingungen nun komplett prüft oder nur die Bedingungen hinschreibt... Eine Funktion wie Assert für diese Fälle kann man auch selbst schreiben, die das Ergebnis prüft.

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 (bzw. falsch) rumklickt.

Mit echten Code Contracts sagt Dir aber schon der Compiler, das der eine Aufruf nicht passt weil er den Contract verletzt. Der Mehrwert ist nicht zu unterschätzen.

[jaenicke]

Dass der Compiler so etwas erkennt, dürfte in echtem Code allerdings gegen Null gehen. Denn um bei deinem Beispiel zu bleiben eine Funktion absichtlich mit nil aufrufen, wenn die Funktion das gar nicht unterstützt, das mag vielleicht mal passieren, fällt aber beim Test auf und ist leicht zu finden.

Viel wahrscheinlicher und vor allem schwerer zu finden sind aber doch Fehler, die durch zur Laufzeit veränderte Variablen entstehen. Und die kann der Compiler ohnehin nicht erkennen.

[Phoenix]

Zitat von jaenicke:

Viel wahrscheinlicher und vor allem schwerer zu finden sind aber doch Fehler, die durch zur Laufzeit veränderte Variablen entstehen. Und die kann der Compiler ohnehin nicht erkennen.

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 konsequent durchzieht werden die Contracts direkt gegeneinander validiert und es ist zur Compilezeit möglich sämtliche Fehler durch falsche Ein- und Ausgabeparameter auszufiltern.

[Meflin]

Zitat von Phoenix:

Genau das ist ja gerade die Mächtigkeit von Design by Contract. Wenn man das konsequent durchzieht werden die Contracts direkt gegeneinander validiert und es ist zur Compilezeit möglich sämtliche Fehler durch falsche Ein- und Ausgabeparameter auszufiltern.

Sehe ich völlig anders. Compile-Time Checking von Contracts ist sicherlich ein nice to have, ist aber in der Perfektion äquivalent zur Lösung des Halteproblems (und ist damit unmöglich). Der wichtige Teil an Contracts ist also durchaus der zur Laufzeit Es sei denn deine Aussage bezog sich jetzt wirklich absolut ausschließlich auf falsche Parameter. Dann kann ich nur sagen: Contracts können weit mehr als das.

[Stevie]

Was die Laufzeit Auswertung angeht, kann man das über AOP machen.

[dominikkv]

Zitat von jaenicke:

Ich sehe allerdings nicht viele Vorteile gegenüber rein eigenem Code. Denn angeben muss man das so oder so und ob man die Bedingungen nun komplett prüft oder nur die Bedingungen hinschreibt... Eine Funktion wie Assert für diese Fälle kann man auch selbst schreiben, die das Ergebnis prüft.

Bei Objekten kann man natürlich die Preconditions mit Assert() prüfen, auch für die Postconditions kann man den Aufwand treiben. Allerdings ist dies dann Code, der in der Methode selbst ausgeführt wird. Das bedeutet, die Methode wird mit zusätzlichem Code aufgebläht, es vermischt sich Contract-Code mit normalem Code und der Sinn / Zweck des Contract-Codes ist nicht auf den ersten Blick ersichtlich.

Außerdem gehört das dann zum Verhalten des Objektes, und nicht zum Datentyp an sich. Der Vertrag vermischt sich mit der Implementierung.

Des Weiteren gibt es ein Einsatzgebiet bei dem das nicht funktioniert: abstrakte Datentypen. Einem Interface kannst du Pre- und Postconditions nicht beibringen. Da Interfaces für mich immer wichtiger werden (man soll mit Interfaces arbeiten, nicht direkt mit Objekten) habe ich gehofft, dass es ein Plugin / Addon für Delphi gibt. In Java kenne ich eins, dass dies mit Hilfe von Annotations umsetzt. Da man in Delphi auch Annotations einsetzen kann dachte ich, ich frag mal hier

[jaenicke]

Pluginmäßig lässt sich das denke ich in Delphi nicht umsetzen. Annotationen in Java bieten ganz andere Möglichkeiten...