数年前、私はJava用のDbCパッケージの調査を行いましたが、それらのいずれにも完全には満足していませんでした。残念ながら、私は自分の発見について良いメモをとっていませんでした、そして私は物事が変わったと思います。 Java用のさまざまなDbCパッケージを比較対照したいと思う人はいますか?
契約による設計に関するWikiPedia に関する素晴らしい概要があり、最後に サードパーティのサポートライブラリを備えた言語 に関するセクションがあり、Javaライブラリ。これらのJavaライブラリのほとんどは、Javaアサーションに基づいています。
前提条件のチェック だけが必要な場合は、軽量の メソッド引数の検証 ソリューションもあります。SourceForgeの Java引数の検証 (プレーンJava実装)。
問題によっては、おそらく OVal フレームワークであり、フィールド/プロパティの制約の検証が適切な選択です。このフレームワークを使用すると、あらゆる種類の異なる形式(注釈、POJO、XML)で制約を配置できます。 POJOまたはスクリプト言語(JavaScript、Groovy、BeanShell、OGNL、MVEL)を通じて顧客の制約を作成します。そしてそれはまたパーティを実装します 契約によるプログラミング 。
Googleには Javaの契約 というオープンソースライブラリがあります。
Javaの契約は、新しいオープンソースツールです。前提条件、事後条件、および不変条件は、Java注釈内のブール式として追加されます。デフォルトでは、これらは何もしませんが、 JVM引数を介して有効にすると、実行時にチェックされます。
• @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
Javaの契約 。
Groovy/JavaコードでDesignby Contract(tm)を有効にするGroovy拡張機能があります GContracts 。いわゆるクロージャアノテーションを使用して、クラスの不変条件、事前条件と事後条件を指定します。例はプロジェクトのgithub wikiにあります。
主な利点:外部依存関係のない単一のjarであり、 中央のMavenリポジトリ に配置されているため、Maven準拠のリポジトリを介して解決できます。
私はcontract4Jを1回テストしましたが、使用可能であるが完璧ではないことがわかりました。クラス全体のメソッド呼び出しとインバーの前後のコントラクトを作成しています。
コントラクトは、メソッドのアサーションとして作成されます。問題は、コントラクト自体が文字列で記述されているため、コントラクトのIDEサポート、またはコントラクトが引き続き機能する場合のコンパイル時のチェッキングがないことです。
library へのリンク
私がこれらを見てから久しぶりですが、古いリンクをいくつか見つけました。 1つは [〜#〜] jass [〜#〜] 用でした。
私が使用した(そして気に入った)もう1つは、ReliableSystemsのiContractでした。プリプロセッサとして実行するアリタスクがありました。しかし、グーグル検索で見つけられないようで、消えてしまったようです。元のサイトは現在、リンクファームです。それに到達するためのいくつかの可能な方法については このリンク をチェックしてください。
いくつかのツールの組み合わせをお勧めします。
Javaの_assert condition...
_またはそれより高度なGroovyのいとこ、Guavaの Preconditions.checkXXXX(condition...)
およびVerify.verify(condition...)
、または AssertJ のようなライブラリ必要なのが「メイン」または「テスト」コードで簡単なチェックを行うことだけである場合
OVal などのツールを使用して、より多くの機能を利用できます。オブジェクトとメソッドの引数および結果の両方をチェックできます。また、手動でチェックを実行することもできます(たとえば、メソッドが呼び出される前にUIで検証エラーを表示するため)。たとえば、JPAまたは_javax.validation
_(_@NotNull
_、_@Pattern
_、_@Column
_など)からの既存の注釈を理解できます。または、@Pre(expr="x >= 0 && x <= y")
のようなインライン制約を記述できます。アノテーションが_@Documented
_の場合、チェックはJavadocにも表示されます(そこでもチェックを記述する必要はありません)。
OValはリフレクションを使用します。これにより、Androidなどの一部の環境でパフォーマンスの問題やその他の問題が発生する可能性があります。次に、 GoogleのCofoja のようなツールを検討する必要があります。これは機能が少なくなりますが、リフレクションではなくコンパイル時の注釈処理ツールに依存します
Javaモデリング言語( [〜#〜] jml [〜#〜] )を検討することを強くお勧めします。
コントラクトを表現するためのわかりやすくシンプルな基本サポートが必要な場合は、valid4j(Maven Centralでorg.valid4j:valid4jとして見つかります)を参照してください。通常のハムクレストマッチャーを使用して、プレーンコード(注釈やコメントなし)で契約を表現できます。
前提条件と事後条件の場合(基本的にアサーション-> AssertionErrorのスロー):
import static org.valid4j.Assertive.*;
require(inputList, hasSize(greaterThan(0)));
...
ensure(result, lessThan(4.0));
デフォルトのグローバルポリシー(AssertionErrorをスローする)に満足できない場合、valid4jは、org.valid4j.AssertiveProviderの独自の実装を提供できるカスタマイズメカニズムを提供します。
リンク:
Java 1.4:から導入された組み込みのassertキーワードによって、多くのDbCライブラリが上回ったと思います。
個人的には、現在利用可能なDbCライブラリーには多くの要望が残されていると思います。私が調べたライブラリーはどれも、Bean ValidationAPIでうまく機能しませんでした。
私が見たライブラリは文書化されています ここ
Bean Validation APIには、DbCの概念と多くの重複があります。場合によっては、Bean Validation APIを単純なPOJO(非CDIマネージコード)のように使用できないことがあります。 Bean ValidationAPIのIMOthinkラッパーで十分です。
既存のライブラリは、AOPまたはバイトコードインストルメンテーションのいずれかを介して実装されているため、既存のWebプロジェクトに追加するのは少し難しいことがわかりました。おそらくBeanValidation APIの出現により、DbCを実装するためのこの種の複雑さは保証されていません。
私はまた、これで私の暴言を文書化しました post そしてBean ValidationAPIを活用する小さなライブラリを構築したいと思っています