問題タブ [design-by-contract]

コントラクトによるプログラミングは.NETの最近の傾向ですが、PHPのコードコントラクトのライブラリ/フレームワークはどうでしょうか。このパラダイムのPHPへの適用性についてどう思いますか？

「コードコントラクトphp」をグーグルで検索しても何も得られませんでした。

注：「契約によるコード」とは、契約による設計を意味するため、.NETまたはPHPインターフェースとは何の関係もありません。

バックグラウンド：

新しい組み込みシステムのファームウェアをモデル化しています。現在、ファームウェアはUMLでモデル化されていますが、UMLモデリングツールのコード生成機能は使用されません。

ターゲット言語はC（具体的にはC99）になります。

低電力（つまり、パフォーマンス、迅速な実行）と正確さは重要ですが、コードサイズや実行速度など、何よりも正確さが最優先事項です。

システムのモデリングでは、明確に定義されたコンポーネントのセットを特定しました。各コンポーネントには独自のインターフェースがあり、多くのコンポーネントが多くのコンポーネントと相互作用します。

モデル内のほとんどのコンポーネントは、リアルタイムオペレーティングシステム（RTOS）での個別のタスク（スレッド）になりますが、一部のコンポーネントはライブラリにすぎません。タスクは、メッセージパッシング/キュー投稿を介して完全に相互に通信します。ライブラリとの相互作用は、同期関数呼び出しの形式になります。

アドバイス/推奨事項は規模によって異なる場合があるため、いくつかの情報を提供します。現在、約12〜15個のコンポーネントがありますが、最大20個に増える可能性がありますか？数百のコンポーネントではありません。平均して、各コンポーネントが他のコンポーネントの25％と相互作用するとします。

コンポーネント図には、コンポーネント間のインターフェイスを表すために使用されるポート/コネクタがあります。つまり、一方のコンポーネントが他方のコンポーネントに必要なものを提供します。ここまでは順調ですね。

ここにこすりがあります。「コンポーネントA」が「コンポーネントB」のすべてのインターフェースにアクセスできないようにする場合が多くあります。つまり、コンポーネントAをコンポーネントBが提供するインターフェースのサブセットに制限したい場合があります。

質問/問題：

コンポーネント図で定義されたインターフェイスコントラクトを（できればコンパイル時に）強制するための体系的でかなり簡単な方法はありますか？

明らかに、コンパイル時のソリューションは実行時のソリューションよりも望ましいです（より早い検出、より良いパフォーマンス、おそらくより小さなコード）。

たとえば、ライブラリコンポーネント「B」が関数X（）、Y（）、およびZ（）を提供するとしますが、コンポーネント「A」が関数Z（）のみを呼び出し、X（）およびY（）を呼び出せないようにします。 。同様に、コンポーネント「A」は、メッセージキューを介して多数の異なるメッセージを受信して​​処理できる場合でも、メッセージを任意のコンポーネントに送信できるコンポーネントはありません。

私が思いついた最善の方法は、コンポーネントとコンポーネントのインターフェイスごとに異なるヘッダーファイルを用意し、コンポーネントが使用を許可されているインターフェイスの部分のみを（ヘッダーファイルを介して）公開することです。明らかに、これにより多くのヘッダーファイルが作成される可能性があります。これは、コンポーネント間でのメッセージパッシングがOS APIで直接行われるのではなく、それぞれが特定の（許可された）メッセージを作成して送信する関数呼び出しを介して行われることも意味します。同期呼び出し/ライブラリの場合、APIの許可されたサブセットのみが公開されます。

この演習では、人々が行儀が良いと想定できます。 言い換えれば、関数プロトタイプを直接不正行為、切り取り、貼り付けしたり、許可されていないヘッダーファイルをインクルードしたりすることを心配する必要はありません。許可されていない場合、「A」から「B」へのメッセージを直接投稿することはありません。

コンパイル時のアサーションを使用してコントラクトを適用する方法があるかもしれません。オーバーヘッドが発生したとしても、実行時にこれをチェック/実施するためのより洗練された方法があるかもしれません。

コードはクリーンにコンパイルおよびリントする必要があるため、「関数プロトタイプファイアウォール」アプローチは問題ありませんが、これを行うにはもっと慣用的な方法があるようです。

IEnumerable を返す次の 2 つのメソッドを検討してください。

このコードは、IEnumerable のメソッドを呼び出すときの 2 つの異なる動作を示しています。

コードが IEnumerables を返すときに必要な動作を選択するのは簡単ですが、「First()」メソッドを呼び出す回数に関係なく、単一の結果セットを作成するパラメーターとして一部のメソッドが IEnumerable を取得することを明示的に定義するにはどうすればよいでしょうか。

もちろん、すべての itens を不必要に強制的に作成したくはありません。また、パラメーターを IEnumerable として定義して、コレクションに含まれるアイテムやコレクションから削除されるアイテムがないことを示したいと考えています。

EDIT：明確にするために、問題はyieldがどのように機能するか、またはIEnumerableが呼び出しごとに異なるインスタンスを返す理由についてではありません。問題は、「First()」や「Take(1)」などのメソッドを数回呼び出したときに、パラメーターが MyClass の同じインスタンスを返す「検索のみ」のコレクションになるように指定するにはどうすればよいかということです。

何か案は？

前もって感謝します！

契約による設計は特急仕様に限界があるようです。例えば ​​Stack FILO プロパティをコントラクトで表現しようとしたのですが、思いつきませんでした。誰でも助けることができますか？

根本的な原因は、前提条件/事後条件/不変条件が副作用のないアサーションであることだと思います。それは、容易ではない副作用の一種である FILO プロパティのチェックにつながります。

先日コード コントラクトのデモを見て、小さなテスト プロジェクトで試してみることにしました。

「using System.Diagnostics.Contracts」ステートメントをクラスに追加した後、コード コントラクト コードを適切にセットアップできますが、コントラクトが強制されていないようです。

プロジェクトのプロパティ画面に [Code Contracts] タブが表示されない理由はありますか?

以下は非常に簡単な例です。静的解析の警告をオンにすると、まだ 警告 CodeContracts: ensure unproven: Contract.Result() != string.Empty が表示されます

ライン上

return string.Format("{0}, {1}", movie.Title, movie.Description);

以下のコードを参照してください

何か案は？

Code ContractC# 4.0 には、事後条件と事前条件を実装するために使用できる機能があることを知っています。しかし、C# 3.0 のみを使用して実装したいと考えています。私は自分の仕事でこの機能を使用することを実験しています。attributes事後条件と事前条件を実装するために使用することは可能ですか?

何かアドバイスはありますか？

ありがとう。

これは実際には設計上の質問です。JSONペイロードを運ぶSpring3.0RESTWebサービスが、コントラクトファースト設計に従う従来のWebサービスと同様のある種のデータコントラクトを提供するかどうか疑問に思います。JSONにはXSDに似たスキーマがあることは知っていますが、春にはどこに適合しますか？背景：クライアントが.NETベースのアプリケーションであり、データコントラクトがクライアントの複数のバージョンを処理する方法を提供するクライアントサーバーアーキテクチャプロジェクトのペイロードとしてjsonを使用することを検討しています。クライアントは、データ構造をサーバーに送信できる必要があります。または、スキーマを使用しないアプローチを採用し、XmlAnyElementに類似した「SimpleDataBinding」を使用する必要がありますか？

C ++でクラスの不変条件をチェックするための確立されたパターンはありますか？

理想的には、不変条件は、各パブリックメンバー関数の最初と最後に自動的にチェックされます。私の知る限り、クラス付きのCは特別なメンバー関数を提供してbeforeいafterましたが、残念ながら、契約による設計は当時あまり人気がなく、Bjarne以外はその機能を使用していなかったため、彼はそれを削除しました。

もちろん、check_invariants()各パブリックメンバー関数の最初と最後に手動で呼び出しを挿入するのは面倒でエラーが発生しやすくなります。RAIIは例外を処理するための最適な武器であるため、不変チェッカーを最初のローカル変数として定義する次のスキームを考え出しました。不変チェッカーは、構築時と破棄時の両方で不変条件をチェックします。

質問＃0：名前のないローカル変数を宣言する方法はないと思いますか？:)

コンストラクタの最後とデストラクタの最初check_invariants()で手動で呼び出す必要があります。ただし、多くのコンストラクタボディとデストラクタボディは空です。その場合、最後のメンバーとしてを使用できますか？FooFooinvariants_checker

質問1：オブジェクトがまだ作成中であっても、そのポインターを介してすぐに呼び出すコンストラクターに渡すthisことは有効ですか？invariants_checkercheck_invariantsFoo

質問2：このアプローチで他に問題がありますか？改善できますか？

質問3：このアプローチは新しいものですか、それともよく知られていますか？より良い解決策はありますか？

契約による設計手法をコーディングスタイルに取り入れようとしています。事後条件は、埋め込まれた単体テストのように私にはよく見えます。ここでの私の考えは、正しい方向に進んでいるのか、それともベースから外れているのか疑問に思っています。

ウィキペディアでは、事後条件を「コードの一部のセクションの実行直後、または正式な仕様での操作後に常に真でなければならない条件または述語。事後条件は、コード自体の中でアサーションを使用してテストされる場合があります」と定義しています。

これは、状態を直接検証する（モックを使用しない）単体テストで行うこととあまり似ていませんか？

だとしたら：

1）事後条件を使用することで、テストコードを本番コードに埋め込んでいるのではないでしょうか。また、それは眉をひそめているのではないでしょうか。

2）事後条件を使用すると、単体テストの構造を変更する必要がありますか？私の最初の考えは、アサーションロジックがテストから事後条件に移行することです。つまり、テストは同じ入力を使用し、以前にテストしていたすべてのものをテストしていますが、単体テストでアサーションを作成する代わりに、事後条件が合格するかどうかについて単純なバイナリアサーションを作成しています。

3）私の第二の考えは、事後条件コードには制御フローがある可能性があるため、単純で制御フローを回避することになっているテストコードには理想的ではないということです。しかし、事後条件をテストする場合、単体テストでそれらを信頼できますか？

4）事後条件をテストするのは難しいようです。正しく理解すれば、基本的に合格または不合格であり、事後条件自体のロジックを繰り返して、それが正しいことを確認する必要があるためです。では、どのように事後条件をテストしますか？単体テストでそれらを利用せず、単体テストと事後条件が一緒に合格または不合格になることを確認して、それらをチェックしますか？

5）ユニットテストでは、メソッドによって共同作業者の状態が変化したことが確認されることがあります。標準的な方法では、事後条件はコラボレーターの状態をカバーしますか、それともそれらが定義されているクラスの状態のみをカバーしますか？