Kilka lat temu zrobiłem ankietę dotyczącą pakietów DbC dla Javy i nie byłem w pełni zadowolony z żadnego z nich. Niestety nie zachowałem dobrych notatek na temat moich ustaleń i zakładam, że coś się zmieniło. Czy ktokolwiek chciałby porównać i porównać różne pakiety DbC dla Javy?Dobra biblioteka "Projektuj z kontraktu" dla Javy?
Istnieje piękny przegląd na WikiPedia about Design by Contract, na końcu znajduje się sekcja dotycząca languages with third party support libraries, która zawiera ładną serię bibliotek Java. Większość z tych bibliotek Java bazuje na Asercji Java.
W przypadku, gdy potrzebujesz tylko Precondition Checking, jest również lekkie rozwiązanie Validate Method Arguments, pod SourceForge pod Java Argument Validation (implementacja Plain Java).
W zależności od problemu, być może ramy OVal dla sprawdzania ograniczeń pola/własności są dobrym wyborem. Ta struktura umożliwia umieszczanie ograniczeń we wszystkich różnych formach (Adnotacje, POJO, XML). Twórz ograniczenia klientów poprzez POJO lub języki skryptowe (JavaScript, Groovy, BeanShell, OGNL, MVEL). I to także strona implementuje Programming by Contract.
myślę, że wiele bibliotek DBC zostały surclassed przez wbudowanym assert hasła, wprowadzonego od Java 1.4:
ale Sun pisze: „Nie używać twierdzeń, by sprawdzić parametry metody publiczne” w http : //java.sun.com/javase/6/docs/technotes/guides/language/assert.html –
Co więcej, DbC powinno ułatwić dodawanie umów do Twojego kodu. Jeśli nie jest to łatwe, większość programistów tego nie zrobi. Możliwe jest implementowanie niezmienników klas za pomocą asercji i wywołań do metody niezmienniczej klasy, ale jest ona niezgrabna. –
Raz testowałem contract4J i okazało się, że jest użyteczne, ale nie doskonałe. Tworzysz kontrakty dla i po wywołaniach metod i inwokacjach dla całej klasy.
Kontrakt jest tworzony jako asercja dla metody. Problem polega na tym, że sam kontrakt jest napisany w łańcuchu, więc nie masz wsparcia IDE dla umów lub kompilacji czasu, jeśli umowa nadal działa.
Link do library
Minęło sporo czasu odkąd spojrzał na nich, ale znalazłem kilka starych linków. Jeden był dla JASS.
Drugim, którego użyłem (i polubiłem) było iContract by Reliable Systems. Miał ant zadanie, które można uruchomić jako preprocesora. Jednak nie mogę znaleźć go w niektórych wyszukiwaniach w Google, wygląda na to, że zniknął. Oryginalna strona jest teraz farmą linków. Sprawdź numer this link pod kątem kilku możliwych sposobów, aby się do niego dostać.
Najnowsza wersja JASS pochodzi z lipca 2005. Nie zamierzam spekulować na temat wersji JDK, którą obsługuje. JASS ma jednak link do JML, który wydaje się być pod aktywnym rozwojem. –
Gorąco polecam rozważenie języka modelowania Java (JML).
Istnieje rozszerzenie Groovy, które umożliwia projektowanie według umowy (tm) w kodzie Groovy/Java - GContracts. Korzysta z tak zwanych adnotacji zamknięcia, aby określić niezmienniki klasy, warunki wstępne i końcowe. Przykłady można znaleźć na wiki github projektu.
Główna zaleta: jest to tylko pojedynczy słoik bez zewnętrznych zależności i można go rozwiązać za pomocą repozytoriów zgodnych z Maven, ponieważ został umieszczony w the central Maven repo.
Nie sądzę, możemy użyć GContracts w projekcie Java, ponieważ GContracts intensywnie korzysta z Groovy Closures – Sudarshan
To prawda, jest to biblioteka tylko Groovy. –
Google ma bibliotekę open source o nazwie contracts for java.
Umowy na Javę to nasze nowe narzędzie open source. Warunki wstępne, warunki końcowe i niezmienniki są dodawane jako wyrażeń logicznych Java wewnątrz adnotacji. Domyślnie te nic nie robią, ale są włączane przez argument JVM , są sprawdzane w środowisku wykonawczym.
• @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
Osobiście uważam, że dostępne obecnie biblioteki DbC pozostawiają wiele do życzenia, żadna z bibliotek, które oglądałem, nie grała dobrze z API Walidacji Fasoli.
Biblioteki i spojrzał zostały udokumentowane here
The Bean Validation API ma dużo na kolanach z pojęciami z DBC. W niektórych przypadkach API walidacji Bean nie może być używane tak jak proste POJO (kod nie zarządzany przez CDI). IMO powinno być wystarczającym rozwiązaniem dla wrappera wokół API Walidacji Fasoli.
Zauważyłem, że istniejące biblioteki są nieco trudne do dodania do istniejących projektów internetowych, ponieważ są zaimplementowane za pomocą AOP lub oprzyrządowania Bajt. Prawdopodobnie wraz z pojawieniem się API Bean Validation tego rodzaju złożoność implementacji DbC jest nieuzasadniona.
Mam również udokumentowane mój rant w tym post i nadzieję zbudować małą bibliotekę, wykorzystującą na API Bean Validation
Jeśli chcesz zwykły i prosty podstawowe wsparcie dla wyrażania swoich umów, rzucić okiem na valid4j (znaleziono na Maven Central jako org.valid4j: valid4j). Umożliwia wyrażanie zamówień za pomocą zwykłych kodów kreskowych w zwykłym kodzie (bez adnotacji i komentarzy).
Dla uwarunkowań i postconditions (zasadniczo twierdzeń -> rzucanie AssertionError):
import static org.valid4j.Assertive.*;
require(inputList, hasSize(greaterThan(0)));
...
ensure(result, lessThan(4.0));
Jeżeli nie jesteś zadowolony z domyślnej polityki globalnej (rzucanie AssertionError) valid4j zapewnia mechanizm dostosowywania że Chodźmy podać własne implementacja org.valid4j.AsertiveProvider.
Linki:
Ktoś ma arkusz kalkulacyjny porównań dla tego? Macierz funkcji byłaby świetna. –
valid4j bardziej przypomina bibliotekę asercji (podobnie jak popularna assert Java lub zaawansowany assert Groovy), a nie jak pełne narzędzie DBC (jak OVal czy Cofoja) – iirekm
Proponuję połączenie kilku narzędzi:
Java assert condition... czy to bardziej zaawansowany Groovy kuzyn, guawa na Preconditions.checkXXXX(condition...) i Verify.verify(condition...) lub biblioteka taka jak AssertJ, jeśli wystarczy tylko wykonać proste sprawdzenia w kodzie głównym lub testowym, aby uzyskać więcej funkcji za pomocą narzędzia takiego jak OVal; może sprawdzać zarówno obiekty, jak i argumenty metod i wyniki, można również ręcznie uruchamiać kontrole (np. wyświetlać błędy sprawdzania poprawności w interfejsie użytkownika przed wywołaniem metody). Rozumie istniejące adnotacje, np. Z JPA lub javax.validation (np. @NotNull, @Pattern, @Column), lub można pisać ograniczenia w linii, takie jak @Pre(expr="x >= 0 && x <= y"). Jeśli adnotacja to @Documented, kontrole będą również widoczne w Javadocs (nie musisz ich również tam opisywać).
OVal używa refleksji, która może powodować problemy z wydajnością i inne problemy w niektórych środowiskach, takich jak Android; Następnie należy rozważyć narzędzia takie jak Google's Cofoja, który ma mniej funkcji, ale zależy od kompilacji adnotacji Processing narzędzia zamiast refleksji
OVal wygląda imponująco. Powiedziałbym, że jest tak dobry, jak DbC w Javie. –
Nie jestem pewien, czy komentarz jest najlepszym miejscem/sposobem, ale tylko dla następnych czytających: [Contracts for Java - cofoja] (http://code.google.com/p/cofoja/) to ostatnie dodatek prosto z 20-procentowego badania Google. – superjos