問題タブ [design-by-contract]

ラケットコントラクトシステムを使用していますが、引数のない関数をエクスポートしたいと思います。これは、引数のないラムダ式を返します。例：

この種の機能の契約書を書く方法を知っている人はいますか？

契約による設計の部分的な実施のアイデアについて、いくつかの意見を聞きたいと思います。目標は、外部ライブラリを必要とせずに、ライトバージョンのコントラクト（不変条件と事後条件のみ）を提供しない言語に追加することです。

私の例はJavaで書かれていますが、このアイデアは多くのオブジェクト指向言語に適していると思います。

次のようなクラスがあります。

上記のコードを次のように拡張します。

このアプローチの制限：
-前提条件はありません。
-コントラクトは継承されません（ただし、不変条件と事後条件は保護されており、サブクラスで再利用できることに注意してください）。
-不変条件と事後条件がオブジェクトの状態を変更しないというチェックはありません。したがって、副作用のリスクがあります。
-契約は明確な方法で私たちの文書の一部ではありません。
-すべてのクラスを複製可能にする必要があります。

さて、いくつかの質問：
-この方法はパフォーマンスに何らかの影響を及ぼしますか？アサーションが無効になっている場合、古いローカル変数とresローカル変数でさえJITコンパイラによって削除されるということですか？
-このアプローチの欠点はありますか？なぜあなたはあなたのクラスでこれを使わないのですか？
-改善を提案できますか？

読んでいただきありがとうございます。

I know that both Eiffel (the progenitor) and Racket both to implement "Design by Contract" features. Sadly, I am not sure how one would different from the other. Eiffel's DBC is reliant on the OOP paradigm and inheritance, but how would Racket, a very different language account for such a disparity?

私は前提条件とそれらをいつ使用するかについて学んでいます。前提条件は

次のコードには適合しません。

どうしてこれなの？

編集：別の例

例として、次のことが「正しい」方法で行われると想定しています。IllegalArgumentExceptionと前提条件に注意してください。動作がどのように明確に定義されているか、および前提条件が設定されている場合でもthrows宣言がどのように行われるかに注意してください。最も重要なことは、NullPointerExceptionの前提条件が含まれていないことに注意してください。もう一度、なぜそうではないのですか？

これらの例は、余分な前提条件の使用を回避していますか？前提条件を回避しているのなら、なぜそれらを持っているのでしょうか。つまり、すべての前提条件を@throws宣言に置き換えてみませんか（それらを回避することがここで行われている場合）？

インターフェイスメソッドはパブリックのみであるため、言語でこれを行うことはできません プライベートメソッドを強制する方法は?

代わりに契約による設計を使用できますか？

アプリケーションに契約による設計を実装するのに役立つPHP用のフレームワークまたはライブラリはありますか？

最良の場合、コメントに注釈のようなjavadocを使用します。

私は最近、契約による設計とテスト駆動開発を比較した論文を読みました。DbCとTDDの間には、多くの重複、ある程度の冗長性、および少しの相乗効果があるようです。たとえば、契約に基づいてテストを自動的に生成するシステムがあります。

DbCは現代の型システム（haskellや依存型言語の1つなど）とどのように重複しており、両方を使用する方がどちらよりも優れている点はありますか？

StackOverflowには、assertステートメントを使用する必要がある場合と例外をスローする場合の問題について説明するいくつかの質問があります。（ここ、ここ、ここ、ここ、ここ、ここの例。

ただし、assert-vs-throwの従来の知識は、JVM内で実行しているという仮定に基づいているのではないかと思うようになりました。JavaがJavaScriptに変換され、ブラウザーのコンテキストで実行されるGWTユニバースでは、一連のトレードオフの感じが異なります。ブラウザーで実行する場合、アサートは常にコンパイルされ、JavaScriptのサイズを小さく保つものはすべてコンパイルされます。特にWebアプリケーションを携帯電話で実行する必要がある場合は、これがメリットです。ただし、アサートはDevModeで実行されるため、開発中にユーティリティが使用されます。

だから私の質問は次のとおりです：GWTでassertステートメントを使用する方法を管理する一連のベストプラクティスルールについて誰かが考えたことはありますか？チームのメンバーに「アサーションがコンパイルされたので、それを持っているのは理にかなっていますか？」と聞かれましたが、良い答えが欲しいです。

また、GoogleのGWTの開発者がこのテーマに関して持っている哲学について誰かが洞察を持っていますか？GWTソースコードを見ると、彼らはそれを頻繁に使用しているように見えます。

私はこのような方法を作りました

ここで、呼び出し元のコードで null 値を適切に処理する必要があります。このメソッドによって返される null 値を処理できるようにする必要があるすべての呼び出し元の契約を表現する方法はありますか?

私が望むのは、 p が潜在的な問題としてマークされることです。

編集 コードを変更し、呼び出しコードと予想される動作を追加しました。また、メソッド GetPerson におそらく存在しない属性を追加しました

COFOJA を使用してメソッドのコントラクトを作成する必要があるプロジェクトに取り組んでおり、ヒューリスティックを使用してコントラクトからメソッドのコードを生成する必要があります。

1) @requires、@ensures などの COFOJA で使用される注釈をスキャンするにはどうすればよいですか? 2) 抽象構文ツリーを生成する場合、AST に注釈/契約言語も含まれるかどうか?

例：私のプロジェクトへの次の入力を検討してください