Wie populär ist Design by Contract in Java und was haltet ihr davon?

[icarus2]

Hi

Ich hatte letztes Semester eine Vorlesung "Einführung in die Programmierung mit Eiffel", die von Bertrand Meyer gehalten wurde. Natürlich lernten wir da das Design by Contract (Meyer ist ja der Erfinder davon und auch von Eiffel).

Wie sieht es mit DbC in Java aus? Ich habe im Internet verschiedene Ansätze gefunden. Habe auch ein par Artikel darüber gelesen. Nutzt jemand von euch DbC vom programmieren?

Vielleicht etwas zu meiner Erfahrung:
Als ich das erste mal von DbC hörte und es anwenden musste, empfand ich es als lächerlich. Ich dachte, man könnte es onehing nicht brauchen, da die Contracts meistens offensichtlich sind und solche Dinge. Nachdem ich ein halbes Jahr sehr viel mit Contracts programmiert habe habe ich sie jedoch sehr zu schätzen gelernt und aus meiner Sicht ist das DbC äusserst nützlich. Auch wenn es beim programmieren etwas mehr Zeit braucht, so findet man sehr schnell Fehler. Es ist definitiv ein mächtiges Hilfsmittel, um korrekte Software zu entwickeln.

 

[jgh]

ich hatte davon schonmal was gehört, genutzt habe ich es noch nie...und nach kurzen Studium von Dbc der Wiki-Seite, sehe ich -wenn ich ehrlich bin- keine großen Unterschiede zu einem stinknormalen Interface.

Aber wenn du gute Erfahrung damit gemacht hast, würde ich mal interessieren...was denn der große Vorteil von Dbc gegenüber Interfaces ist?

 

[maki]

Aber wenn du gute Erfahrung damit gemacht hast, würde ich mal interessieren...was denn der große Vorteil von Dbc gegenüber Interfaces ist?

DbC bietet mehr Semantik als Interfaces, in Interfaces kannst du ja nur Typen festlegen, mit DbC kannst du für den Inhalt von Parametern Vorbedingungen und Nachbedingungen festlegen.

Es gitb ein neues Google Projekt dazu: cofoja - Project Hosting on Google Code
Leidet imho an 2 Problemen: Strings sind nicht wirklich refactoring freundlich (auch wenn zB. Eclipse auch dafür Unterstützung bietet), und baut auf Java Assertions auf, welche per default abgeschaltet sind.

Es gibt auch einen JSR der in diese Richtung geht(JSR-000303 Bean Validation), aber imho nicht soweit wie Google Contracts.

 

[jgh]

DbC bietet mehr Semantik als Interfaces, in Interfaces kannst du ja nur Typen festlegen, mit DbC kannst du für den Inhalt von Parametern Vorbedingungen und Nachbedingungen festlegen.
...

jepp, das hört sich für mich^^ logisch und nachvollziehbar an...akzeptiert 🙂

 

[musiKk]

Die Semantik von Vor- und Nachbedingungen in Interfaces läuft bisher eben über JavaDoc. Der wahre Gewinn an einer Sprachunterstützung von DbC liegt imho bei den Invarianten. Zustand ist immer schwierig zu beurteilen und Invarianten können dabei sehr helfen.

Betonung auf Sprachunterstützung: Dass die Invarianten in o. g. Projekt als Strings beschrieben werden, sehe ich auch kritisch. Da haben wir im Prinzip einen Compiler im Compiler...

@icarus2: In welchem Zusammenhang hast Du denn DbC in der Praxis verwendet? Eiffel? Java?

 

[icarus2]

@icarus2: In welchem Zusammenhang hast Du denn DbC in der Praxis verwendet? Eiffel? Java?

Ich habe es in Zusammenhang mit Eiffel gebraucht. In Java habe ich noch nie damit gearbeitet.


Ich finde auch die Invarianten unglaublich nützlich, weil die Invarianten einen gewissen Zustand einer Klasse garantieren, der sonst nur sehr mühsam zu überprüfen ist.

Die Preconditions finde ich gut, weil sofort klare Fehlermeldungen geworfen werden, wenn falsche oder ungültige Parameter übergeben werden. Somit ist die Klasse "geschützt" vor falschen Argumenten von aussen. Aus meiner Sicht sind aber auch Postconditions sehr nützlich, da sie dem Benutzer der Schnittstelle gewisse Zustände und ausgeführte Operationen garantieren. Gerade wenn die Implementierung später geändert wird und man vergisst bei der Änderung ein Detail, so wird zur Laufzeit eine klare Fehlermeldung geworfen wegen den Postconditions oder der Invariante (zumindest meinstes).

Was ich noch interessant fand waren die Invariante und Variante bei der Schleife in Eiffel. Ihr kennt ja bestimmt das Halteproblem, also dass ein Programm nicht überprüfen kann, ob ein anderes Program auf einem beliebigen Input hält. Programme, die unter speziellen Bedingungen in einer Endlosschleife enden sind ja nicht gerade wünschenswert, aber gemäss Meyer passiert das oftmals. Er meinte, dass wenn ein Programm "hängen" bleibt, es oftmals daran liegt, dass es sich in einer Endlosschleife befindet. Interessant finde ich nun, dass es in Eiffel mit DbC eine Technik gibt, um oftmals lokal beweisen zu können über eine Invariante und eine Variante, dass die Schleife bei beliebigem Input nach einer endlichen Anzahl schritten terminiert.