問題タブ [design-by-contract]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c#-4.0 - Spec# は使用するのに十分安定していますか?
Spec# を定期的に使用している人はいますか? どこでも使い始める前に、安定して十分に強力かどうかを知りたい. 構文が c# 4.0 に影響しているようです。4.0 がリリースされたら、アップグレードが容易になることを願っています。考え?
perl - Perlで契約によるデザインをどのように行いますか?
私は Perl プロジェクトで DbC を使用して調査しており、ソース内のコントラクトを検証する最良の方法を見つけようとしています (たとえば、事前/事後条件、不変条件のチェックなど)。
Class::Contractは Damian Conway によって書かれ、現在は C. Garret Goebel によって保守されていますが、8 年以上触れられていないようです。
私が使いたいのはMooseのようですが、DbC に使用できる機能を提供するように思われますが、これについてのリソース (記事など) を誰かが持っているかどうか疑問に思っていました。私が見つけられなかった有用なモジュールがそこにある場合。
PerlでDbCをやっている人はいますか? Mooseに「飛び込んで」、Mooseに何ができるか見てみるべきですか?
css - Web 開発で CSS を使用するための契約書を作成する最良の方法は何ですか?
私たちの開発チームは、2 年以上前にエンタープライズ Web ページを開発していました。CSS の使用に関するコントラクトを作成する最良の方法を知りたいと思っています。たとえば、COMP がある場合、開発者とデザイナーが同意し、戻る必要がないように契約に同意する方法。
この種のテクニカル ライティングに利用できるツールはありますか?
CSS と HTML ページの情報のスレッドホールドはどうなっていますか? 一部のデザイナーは、HTML ページに直接入力する必要があると考えています。一般的な意見では、スタイルはすべて CSS に入れ、それ以外はすべて html に入れる必要があります。
ご意見ありがとうございます。
c#-4.0 - マネージド コントラクト ツール ライブラリについてどう思いますか
私は最近、このビデオ http://channel9.msdn.com/pdc2008/TL51/で管理されたコントラクト ツール ライブラリについて見ましたが、これは確かに非常に興味深いものです。悲しいことに、Spec# のようにより洗練された言語自体にこれを含めないようです。実際、Contracts はビジネス コードに多くのノイズを追加するため、C#4.0 では両方のオプションがあると便利です。
ここで誰かがそれを使用して、実際のフィードバックを持っていますか? クラスのプロパティや変数にもコントラクトを追加できますか? 何かのようなもの
よかったかも。
unit-testing - テスト駆動開発と比較して、契約による設計があまり普及していないのはなぜですか?
この質問は、以前に StackOverflow で尋ねられたこの質問のようなものだと思うかもしれません。しかし、私は物事を別の方法で見ようとしています。
TDD では、さまざまな条件、基準、検証コードを含むテストを記述します。クラスがこれらすべてのテストに合格すれば、準備完了です。これは、クラスが実際にやるべきことだけを確実に行う方法です。
Bertrand Meyersの著書Object Oriented Software Constructionを一言一句たどると、クラス自体に内部契約と外部契約があるため、本来の目的のみを実行し、それ以外は何も実行しません。契約が守られていることを確認するためのコードはクラスの一部であるため、外部テストは必要ありません。
物事を明確にするための簡単な例
TDD
すべてのケースで値の範囲が (0 ~ 100) であることを確認するテストを作成します。
テストに合格するメソッドを含むクラスを作成します。
DBC
- クラスを作成し、そのメンバー
var
の範囲を (0-100) にするコントラクトを作成し、コントラクト違反のコントラクトを設定し、メソッドを定義します。
私は個人的にDBCアプローチが好きです。
純粋な DBC があまり普及していない理由はありますか? 言語やツール、アジャイルなのか、それともコードに責任を持つのが好きなのが私だけなのか?
私の考えが正しくないと思われる場合は、喜んで学びます。
c# - メソッドがC#でnull(契約による設計)を返さないことをどのように示すことができますか
nullオブジェクトを返さないメソッドがあります。APIのユーザーが次のようなコードを書く必要がないように、明確にしておきたいと思います。
この意図をどのように示すことができますか?
design-by-contract - null 非許容オブジェクトの何が問題になっていますか?
私は最近、DbC と、null 非許容オブジェクトをサポートしているように見える Spec# を見てきました。残念ながら仕様番号は放棄されたようです。
- Spec# には多くの優れた言語機能が組み込まれているように見えたのに、なぜそれが放棄されたのですか?
- デフォルトですべてのオブジェクトを null 非許容にすることに問題があるので、int?, string? と記述する必要がありますか? さらにMailMessage?本当にnull可能なオブジェクトが必要な場合は?
- ここで、クラス プロパティを null 許容または非 null 許容としてチェックできる SQL の類似性を確認できます。SQL テーブルの列でできるように、プロパティに制約を課すことさえできますか?
このような機能を言語に組み込むことに問題があるとは思いません。誰でもこれについて教えてもらえますか?
c# - DbC (契約による設計) と単体テスト
私は C# 4.0 とのコントラクトを使用していますが、以前は多くの単体テスト (TDD ではありません) を使用していました。DbC によって、外部単体テストを作成する必要がなくなるのでしょうか?
個人的には、コントラクトはコード自体と密接に結びついており、その他の利点があるため、堅牢なフレームワークを作成するにはコントラクトの方が適していると思います。
皆さんはどう思いますか?
domain-driven-design - DbC をサポートするビジネス エンティティ/値オブジェクト フレームワーク
ビジネス モデルを構築するときに最も多くの時間を費やしていると思うのは、ビジネス エンティティの検証と、エンティティ オブジェクトとその関係が適切な整合性を維持していることを確認することです。優れたエンティティ/値オブジェクト フレームワークに対する私の夢は、再利用可能なエンティティ/値オブジェクトを作成し、データベースで行うように関係の制約とルールを簡単に作成するのに役立ちますが、これは本当にビジネス ルールであると感じているため、モデルに属し、そうあるべきです。データベースから完全に独立しています。
Person オブジェクトの Name プロパティが必須であること、Email プロパティが必須であること、および特定の正規表現に一致すること、およびこれらのルールが簡単に再利用可能であることを簡単に定義できる必要があります。私のWebアプリで入力を検証する際に。
私はLinq to sqlの経験が最も豊富で、値オブジェクトなどをサポートしていないため、操作するのは確かに良いことですが、制限があります。私の質問は、エンティティ フレームワークまたは NHibernate がより適しているか、それとも私のニーズにより適した他のテクノロジがあるかということです。