wake-up-neo.net

Eine gute Design-by-Contract-Bibliothek für Java?

Vor ein paar Jahren habe ich eine Umfrage unter DbC-Paketen für Java durchgeführt und war mit keinem von ihnen ganz zufrieden. Leider habe ich meine Ergebnisse nicht gut dokumentiert und ich gehe davon aus, dass sich die Dinge geändert haben. Möchte jemand verschiedene DbC-Pakete für Java vergleichen und gegenüberstellen?

45
Chris Jones

Es gibt eine Übersicht zu Nice in WikiPedia zu Design by Contract . Am Ende gibt es einen Abschnitt zu Sprachen mit Support-Bibliotheken von Drittanbietern , der eine Nice-Serie von Java-Bibliotheken enthält. Die meisten dieser Java-Bibliotheken basieren auf Java Assertions. 

Für den Fall, dass Sie nur Precondition Checking benötigen, gibt es auch eine leichtgewichtige Validate-Methode - Lösung unter SourceForge unter Java-Argumentüberprüfung (Plain-Java-Implementierung).

Abhängig von Ihrem Problem, möglicherweise das OVal - Framework, ist die Validierung von Feld-/Eigenschaftsbedingungen eine gute Wahl. Mit diesem Framework können Sie die Einschränkungen in den verschiedensten Formen (Anmerkungen, POJO, XML) platzieren. Erstellen Sie Kundeneinschränkungen über POJO oder Skriptsprachen (JavaScript, Groovy, BeanShell, OGNL, MVEL). Und es implementiert auch Partei Programmieren durch Vertrag .

22
Verhagen

Google hat eine Open-Source-Bibliothek namens verträge für Java

Verträge für Java sind unser neues Open Source-Tool. Vorbedingungen, Nachbedingungen und Invarianten werden als Java-Boolesche Ausdrücke In Annotationen hinzugefügt. Standardmäßig machen diese nichts, aber sie werden über ein JVM-Argument Aktiviert. Sie werden zur Laufzeit geprüft.

• @Requires, @Ensures, @ThrowEnsures and @Invariant specify contracts as Java boolean expressions
• Contracts are inherited from both interfaces and classes and can be selectively enabled at runtime

Verträge für Java .

6
user

Es gibt eine Groovy-Erweiterung, die Design by Contract (tm) in Groovy/Java-Code - GContracts ermöglicht. Es verwendet so genannte Closure-Annotationen, um Klasseninvarianten, Vor- und Nachbedingungen anzugeben. Beispiele finden Sie im Github-Wiki des Projekts.

Großer Vorteil: Es ist nur ein einziges Glas ohne externe Abhängigkeiten, und es kann über Maven-kompatible Repositorys aufgelöst werden, da es in dem zentralen Maven-Repo abgelegt wurde.

2

Ich habe contract4J einmal getestet und für brauchbar befunden, aber nicht perfekt. Sie erstellen Verträge für und nach Methodenaufrufen und Invars über die gesamte Klasse. 

Der Vertrag wird als Zusicherung für die Methode angelegt. Das Problem ist, dass der Vertrag selbst in einer Zeichenfolge geschrieben ist, so dass Sie keine IDE Unterstützung für die Verträge haben oder die Zeit für die Kompilierung ändern, wenn der Vertrag noch funktioniert. 

Ein Link zur Bibliothek

2
Janusz

Es ist lange her, seit ich mir diese angesehen habe, aber alte Links gefunden. Einer war für JASS

Der andere, den ich benutzt hatte (und mochte), war iContract von Reliable Systems. Es gab eine Ameisenaufgabe, die Sie als Präprozessor ausführen würden. Bei einigen Google-Suchen scheint es jedoch nicht zu finden, es scheint verschwunden zu sein. Die ursprüngliche Site ist jetzt eine Linkfarm. Check out this link für einige Möglichkeiten, um dorthin zu gelangen.

2
mattwright

Ich würde eine Kombination aus ein paar Tools vorschlagen:

  • Javas assert condition... oder der fortgeschrittenere Groovy-Cousin, Guavas Preconditions.checkXXXX(condition...) und Verify.verify(condition...) oder eine Bibliothek wie AssertJ , wenn Sie lediglich einfache Überprüfungen in Ihrem 'main'- oder' test'-Code durchführen müssen 

  • sie erhalten mehr Funktionen mit einem Tool wie OVal ; Es kann sowohl Objekte als auch Methodenargumente und Ergebnisse prüfen, Sie können Prüfungen auch manuell auslösen (z. B. um Validierungsfehler auf der Benutzeroberfläche anzuzeigen, bevor eine Methode aufgerufen wird). Sie können vorhandene Anmerkungen zB von JPA oder javax.validation (wie @NotNull, @Pattern, @Column) verstehen oder Inline-Einschränkungen wie @Pre(expr="x >= 0 && x <= y") schreiben. Wenn die Annotation @Documented ist, sind die Prüfungen auch in Javadocs sichtbar (Sie müssen sie dort auch nicht beschreiben).

  • OVal verwendet Reflektion, was in einigen Umgebungen wie Android zu Leistungsproblemen und anderen Problemen führen kann. Dann sollten Sie ein Tool wie Googles Cofoja in Betracht ziehen, das weniger Funktionalität bietet, jedoch auf das Annotation Processing Tool der Kompilierungszeit und nicht auf Reflektionen angewiesen ist

1
iirekm

Ich würde Ihnen dringend empfehlen, die Java Modeling Language ( JML ) zu berücksichtigen. 

1
reprogrammer

Ich denke, dass viele DbC-Bibliotheken von dem eingebauten Schlüsselwort assert umgeben wurden, das seit Java 1.4 eingeführt wurde:

  • es ist eine integrierte Bibliothek, es ist keine andere Bibliothek erforderlich
  • es funktioniert mit Vererbung
  • sie können auf Paketbasis aktivieren/deaktivieren
  • leicht zu refactoring (z. B. keine Aussagen in Kommentaren)
0
dfa

Ich persönlich glaube, dass die derzeit verfügbaren DbC-Bibliotheken zu wünschen übrig lassen. Keine der Bibliotheken, die ich mir angesehen habe, hat mit der Bean Validation-API gut funktioniert.

Die Bibliotheken, die ich mir angesehen habe, wurden dokumentiert hier

Die Bean-Validierungs-API hat mit den Konzepten von DbC viel zu tun. In bestimmten Fällen kann die Bean Validation API nicht wie einfache POJOs (nicht mit CDI verwaltetem Code) verwendet werden. IMO sollte ein Think Wrapper um die Bean Validation API ausreichen.

Ich fand, dass die vorhandenen Bibliotheken ein wenig kompliziert in bestehende Webprojekte eingefügt werden können, da sie entweder über AOP oder Byte-Code-Instrumentierung implementiert werden. Mit dem Aufkommen der Bean Validation API ist diese Komplexität bei der Implementierung von DbC wahrscheinlich nicht gerechtfertigt.

Ich habe meine Kritik auch in diesem post dokumentiert und hoffe, eine kleine Bibliothek zu bauen, die die Bean Validation API nutzt 

0
Sudarshan

Wenn Sie eine einfache und einfache Basisunterstützung für das Ausdrücken Ihrer Verträge wünschen, werfen Sie einen Blick auf valid4j (auf Maven Central als org.valid4j: valid4j). Sie können Ihre Verträge mit normalen Hamcrest-Matchern im Klartext ausdrücken (keine Anmerkungen oder Kommentare).

Für Vorbedingungen und Nachbedingungen (grundsätzlich Assertions -> AssertionError werfen):

import static org.valid4j.Assertive.*;

require(inputList, hasSize(greaterThan(0)));
...
ensure(result, lessThan(4.0));

Wenn Sie mit der globalen Standardrichtlinie (AssertionError werfen) nicht zufrieden sind, bietet valid4j einen Anpassungsmechanismus, mit dem Sie Ihre eigene Implementierung von org.valid4j.AssertiveProvider bereitstellen können.

Links:

0
keyoxy