エンジニア必須の概念 – 契約による設計と信頼境界線

(Last Updated On: 2019年5月29日)少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。 契約による設計（契約プログラミング）（Design by Contract – DbC）は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。 契約プログラミングとは 契約プログラミングは比較的新しい設計思想で、サポートしている言語にはEffile、D、Clojure、Valaなどがあります。最近作られた言語の多くが契約プログラミングをサポートする機能を持っています。C++、C#やJavaなどでも契約プログラミングをサポートするライブラリが利用できます。契約プログラミングをサポートする言語やライブラリを利用しない場合でも、契約プログラミングの概念を適用すると安全かつ効率が良い開発の手助けになります。 Wikipdiaの

[tookikimie]

“構造化設計に慣れている方の場合、アプリケーションの奥深くにデータや条件など妥当性チェックを埋め込んでしまう傾向にあります。この考え方は既に古い考え方であると捉えるべきでしょう。”

[dhrname]

72年版「構造化プログラミング」におけるダイクストラの不変 (invariant)と比較すると、ホーアの操作（構造化の抽象における第三段階）とごちゃまぜになっているなあ

[yimajo]

“アプリケーションプログラミングにおいて契約による設計を行う場合、信頼境界線を明確に意識する事が必須です。信頼境界線とはプログラムが入力されるデータやプログラムを信用してよいかどうか？を基準に境界線を

[crist18]

契約 Design by Contract

[s-ishigami]

PHP6がないのは、そういうことだったのかー。

[oppara]

エンジニア必須の概念 – 契約による設計と信頼境界線 | yohgaki's blog

[nemoba]

コントローラが制約チェックすると、モデルの再利用時に問題が。DDDな思想でいくならモデルのエントリポイントでもやる。冗長になったりエラー設計が難しいのは確かで、Webのポン出しポン入れ思想とはぶつかる。

[k-holy]

OSやミドルウェアに起因するものなのか、業務上の整合性のためなのか、制限を施したい理由によって必要な層でそれぞれ行うべき。そういう意味では「モデル」が制約を持つこと自体は正しいかと