2010-07-22 7 views
6

Ich habe darüber nachgedacht, ein Java-Framework zu erstellen, mit dem Programmierer Invarianten (Pre- und Post-Conditions) an Schnittstellen angeben können. Der Zweck wäre, Code robuster zu machen und die Anzahl der Komponententests zu reduzieren, die für verschiedene Implementierungen derselben Schnittstelle geschrieben werden müssten.Hinzufügen von Invarianten zu Interfaces in Java

Ich stelle mir vor, eine Methode zur Annotation von Methoden mit Invarianten zu erstellen, die der Programmierer ebenfalls schreiben würde. Z.B.

würde mit einer Anmerkung versehen, um sicherzustellen, dass alle Implementierungen eine sortierte Liste zurückgeben. Diese Anmerkung wäre mit einem Komponententest verknüpft, der zur Kompilierungszeit für jede Implementierung ausgeführt werden könnte.

Ist das eine verrückte Idee oder wäre das für die weitere Programmiergemeinschaft nützlich?

+0

Ich bin mir nicht sicher, ob die Verknüpfung mit Unit-Test eine gute Bewegung während der Kompilierzeit ist. Weil _der Test bestanden hat, ist nur etwas, wenn Sie wissen, was ich meine. Mit einem Aspekt Weber kann ein besserer Ansatz sein, nicht? (Dann ist die nächste Frage - Leistung) – yclian

+2

@yclian, Ich denke, die Idee war, diese Vor- und Nachbedingungen zu verwenden, um verschiedene statische Analysen durchzuführen, um die Anzahl der Komponententests zu reduzieren, die in der Reihenfolge geschrieben werden müssten um eine gleichwertige Abdeckung zu erhalten. Ich sah keine Implikation, dass dies notwendigerweise eine Laufzeit-Sache sein würde (obwohl vielleicht einige Laufzeit-Behauptungen verwendet werden könnten, um Aussagen zu schützen, dass statische Analyse nicht sicher sein könnte). – Gian

Antwort

4

Das klingt, als könnte es mit JML und ESC/Java verwandt werden, die beide eine relativ weit verbreitete Annahme innerhalb der Arten von Projekten gefunden haben, die ein wenig mehr Softwarequalität benötigen, als durch die übliche Reihe von Techniken angeboten wird.

+0

Danke, ich werde einen Blick auf JML – Tarski

+1

Ich habe noch nie davon gehört. "Ziemlich weit verbreitete Adoption" - bitte Daten. Ich wette, Sie haben keinerlei Grundlage für diese Aussage, außer für ein oder zwei Projekte, die Sie gemacht haben. – duffymo

+1

@duffymo, ich denke nicht, dass der aggressive Ton notwendig ist. Ich habe mich für eine "relativ weit verbreitete Adoption" qualifiziert. Ich habe die Aussage auf die Tatsache gestützt, dass es in mindestens einigen Universitäten gelehrt wird, von denen ich weiß, dass es ein ziemlich gesundes Ökosystem von JML-Werkzeugen gibt (http://en.wikipedia.org/wiki/Java_Modeling_Language#Tool_Support), und die meisten professionellen Ingenieure sind wahrscheinlich zumindest mit JML als Konzept vertraut. Es gibt auch eine angemessene Anzahl von Peer-Review-Publikationen, die sich mit JML befassen (http://scholar.google.com/scholar?hl=de&q=java+modeling+language). – Gian

0

Was für eine großartige Programmieridee ist nicht verrückt !!! Ich denke definitiv, dass es nützlich wäre.

+2

Einverstanden, aber sollte das nicht ein Kommentar sein? – whiskeysierra

1

Ich denke, Bertrand Meyer Programmierung nach Vertragsidee ist weitgehend tot. Er baute Vor-und Nachbedingungen in Eiffel, aber diese Sprache ist unter Latein auf der Nutzungsskala.

Es gibt Java-Programmierung von Vertragsbibliotheken da draußen; Contractor ist eins. Aber sein Tag ist gekommen und vergangen. Tatsache ist, dass sogar Eiffel eine Möglichkeit hatte, sie in der Produktion auszuschalten, weil die Laufzeitkosten den Nutzen nicht wert waren.

Nur 6 Eiffel-Fragen zu Stack Overflow - ein kleiner Prozentsatz. Wenn Sie nach SO-Tags mit "Vertrag" suchen, sehen Sie eine sehr kleine Zahl. Nicht viel Interesse an dem Thema auf dieser Seite. Es behauptet, das größte Publikum von professionellen Programmierern in der Welt zu ziehen.

+0

interessante Ansichten. Würden Sie sagen, dass eine testgetriebene Entwicklung ein besserer Ansatz ist als eine vertragliche Planung? – Tarski

+0

"Würden Sie sagen, dass eine testgetriebene Entwicklung ein besserer Ansatz ist als eine vertragliche Planung?" - absolut. Es gibt keine Laufzeitstrafe; sie liefern bessere Informationen über das Verhalten von Klassen; Sie dokumentieren viel besser als Verträge. Bei einer Wahl hätte ich lieber die Tests. – duffymo

+3

Ich würde nicht sagen, dass sie viel besser dokumentieren als Verträge. Mit TDD können Sie einige Eingaben testen, um die Funktionalität zu erweitern, aber ein Kontakt kann in abstrakten Begriffen definieren, was die Funktion tatsächlich tut. z.B. eine summe (x, y) -Funktion könnte Kontrakt zurückgeben x + y, während ein Test könnte nur behaupten, dass Summe (1, 2) = 3 – Tarski

2

Ich denke, Design nach Vertrag ist eine großartige Idee, und ich habe auf Frameworks, die diese Funktionalität in Java bieten, geschaut. Ich denke, was mich zurückgehalten hat, ist, dass es schwierig sein kann, von einem Team Buy-In für diese Art von Frameworks zu bekommen. Ich denke, es wird nur von akademischem Interesse wahrgenommen, was merkwürdig ist, weil es wirklich so ist, als würde man Komponententests innerhalb des Codes einbetten.

Javas Hauptnicken in dieser Richtung, die assert-Aussage, gibt es seit einigen Jahren, aber ich sehe es selten - oft nur in dem Code, den ich selbst schreibe! Es gibt eine Menge Meilen in der Verwendung von Behauptungen (besonders in Kombination mit Komponententests) und ich habe ein paar Fehler gefunden, die sie benutzen, es ist nur schade, dass die Leute sie nicht benutzen.

Cheers,

Ian.

+0

Ich stimme dir zu, dass Behauptungen zu wenig genutzt werden. Ich habe gerade meine SCJP-Prüfung absolviert und Sun empfiehlt die Verwendung von Behauptungen, um nur die Vorbedingungen für private Methoden zu überprüfen. Aber wirklich, es gibt nichts, was Sie daran hindern könnte, sie zu verwenden, um auch die Nachbedingungen zu überprüfen. Das Problem, das ich mit Assertionen habe, ist, dass sie standardmäßig deaktiviert sind - ich würde gerne ein Framework verwenden, das die Zeitüberprüfung kompiliert. – Tarski