45

数年前、私は Java 用の DbC パッケージの調査を行いましたが、完全に満足できるものはありませんでした。残念ながら、私は自分の調査結果を適切に記録していませんでした。状況が変化したと思います。Java 用のさまざまな DbC パッケージを比較対照したい人はいますか?

4

10 に答える 10

23

WikiPedia には Design by Contract に関する優れた概要があり 、最後にサードパーティ サポート ライブラリを使用した言語に関するセクションがあり、Java ライブラリの優れたシリーズが含まれています。これらの Java ライブラリのほとんどは、Java アサーションに基づいています。

事前条件チェックのみが必要な場合は、SourceForge のJava Argument Validation (Plain Java implementation)の下に軽量のValidate Method Argumentsソリューションもあります。

問題によっては、フィールド/プロパティの制約の検証にOValフレームワークが適している場合があります。このフレームワークを使用すると、あらゆる種類の異なる形式 (注釈、POJO、XML) で制約を配置できます。POJO またはスクリプト言語 (JavaScript、Groovy、BeanShell、OGNL、MVEL) を使用して顧客の制約を作成します。また、当事者はProgramming by Contractを実装します。

于 2010-01-30T14:07:39.533 に答える
6

Google には、 contracts for javaと呼ばれるオープン ソース ライブラリがあります。

Contracts for 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 の契約。

于 2013-06-30T05:21:52.407 に答える
2

Groovy/Java コードで Design by Contract(tm) を有効にする Groovy 拡張機能 - GContracts があります。いわゆるクロージャー アノテーションを使用して、クラスの不変条件、事前条件および事後条件を指定します。例は、プロジェクトの github wiki にあります。

主な利点: 外部依存関係のない単一の jar であり、中央の Maven リポジトリに配置されているため、Maven 準拠のリポジトリを介して解決できます。

于 2010-08-03T07:59:19.803 に答える
2

contract4J を 1 回テストしたところ、使用可能であることがわかりましたが、完全ではありませんでした。クラス全体のメソッド呼び出しと invars の for および after のコントラクトを作成しています。

コントラクトは、メソッドのアサーションとして作成されます。問題は、コントラクト自体が文字列で記述されているため、コントラクトの IDE サポートがないこと、またはコントラクトがまだ機能する場合のコンパイル時のチェックがないことです。

ライブラリへのリンク

于 2009-07-02T17:59:15.293 に答える
2

Java Modeling Language ( JML ) を検討することを強くお勧めします。

于 2010-04-18T22:29:41.473 に答える
1

いくつかのツールの組み合わせをお勧めします。

  • 「メイン」または「テスト」コードで簡単なチェックを行うだけでよい場合は、Javaassert condition...またはそれよりも高度な Groovy のいとこ、Guava のPreconditions.checkXXXX(condition...)and Verify.verify(condition...)、またはAssertJのようなライブラリ

  • OValなどのツールを使用すると、より多くの機能が得られます。オブジェクトだけでなく、メソッドの引数と結果の両方をチェックできます。チェックを手動で起動することもできます (たとえば、メソッドが呼び出される前に UI に検証エラーを表示するなど)。javax.validation JPA や( @NotNull、@Pattern、 など) などの既存の注釈を理解するか、 の@Columnようなインライン制約を記述できます@Pre(expr="x >= 0 && x <= y")。アノテーションが の場合@Documented、チェックは Javadocs にも表示されます (そこにも記述する必要はありません)。

  • OVal はリフレクションを使用するため、Android などの一部の環境でパフォーマンスの問題やその他の問題が発生する可能性があります。次に、 Google の Cofoja のようなツールを検討する必要があります。これは機能が少ないですが、リフレクションではなくコンパイル時の注釈処理ツールに依存しています。

于 2016-03-09T14:47:50.200 に答える
0

多くの DbC ライブラリは、Java 1.4 以降に導入された組み込みのassertキーワードによって継承されたと思います。

  • それは組み込みであり、他のライブラリは必要ありません
  • それは継承で動作します
  • パッケージ単位で有効化/無効化できます
  • リファクタリングが容易 (例: コメントにアサーションがない)
于 2009-07-02T17:53:08.487 に答える
0

個人的には、現在利用可能な DbC ライブラリには多くの要望が残されていると思います。私が調べたライブラリのどれも、Bean Validation API でうまく機能しませんでした。

私が見たライブラリはここに文書化されています

Bean Validation API は、DbC の概念と多くの重複があります。場合によっては、Bean Validation API を単純な POJO (非 CDI 管理コード) のように使用することはできません。IMO Bean Validation API のラッパーで十分です。

既存のライブラリは、AOP またはバイト コード インストルメンテーションを介して実装されているため、既存の Web プロジェクトに追加するのが少し難しいことがわかりました。おそらく Bean Validation API の出現により、DbC を実装するためのこの種の複雑さは正当化されなくなりました。

また、この投稿で暴言を文書化し、Bean Validation API を活用する小さなライブラリを構築したいと考えています。

于 2013-09-10T16:11:48.327 に答える