「契約による設計」の版間の差分
imported>Administrator |
(→Eiffel) |
||
(5人の利用者による、間の11版が非表示) | |||
1行目: | 1行目: | ||
− | '''契約による設計''' | + | '''契約による設計'''([[英語]]:Design By Contract、でざいん・ばい・こんとらくと)とは、[[ソースコード]]の中に[[プログラム]]が満たすべき[[仕様]](契約)についての記述を盛り込み、[[設計]]の安全性を高める[[プログラミング]]の技法のひとつ、または[[プログラミング言語]]の機能のひとつである。 |
− | たとえば、ある[[サブルーチン]] | + | '''契約プログラミング'''(Programming By Contract)や、Design by Contract の頭文字である'''DbC''' (でぃーびーしー) とよばれることもある。 |
+ | |||
+ | == 概要 == | ||
+ | たとえば、ある[[サブルーチン]]に[[引数]]があるとして、その引数が[[ぬるぽ]]や[[ぬるり]]になることを防ぐためにサブルーチンの先頭部分で[[nullチェック]]や[[境界チェック]]を行う、などという[[コーディング規約]]に近いものを、[[プログラミング言語]]の[[仕様]]として半ば強制することで、[[静的コード解析]]やドキュメント生成、[[単体テスト]](のテンプレート生成)などを的確かつ効率的に行えるようにし、[[プログラム]]の品質を向上させようというものである。 | ||
== 条件の種類 == | == 条件の種類 == | ||
− | + | 契約は、コードの利用条件が満たされることによって成立する。それら条件は、満たすべきタイミングと主体によって以下の3種類に分けられる。 | |
− | |||
− | ; [[事前条件]] (precondition) :[[サブルーチン]] | + | ; [[事前条件]] (precondition) :[[サブルーチン]]の開始時に、これを呼ぶ側で保証すべき性質。たとえばというか、ほぼ引数の値のチェックである。 |
− | ; [[事後条件]] (postcondition) :[[サブルーチン]] | + | ; [[事後条件]] (postcondition) :[[サブルーチン]]が、終了時に保証すべき性質。たとえば「[[戻り値]]は絶対に[[null]]を返さない」などを決めておくことを言う。 |
; [[不変条件]] (invariant) :[[クラス]]などの[[オブジェクト]]がその外部に公開しているすべての操作の開始時と終了時に保証されるべき、オブジェクト毎に共通した性質。 | ; [[不変条件]] (invariant) :[[クラス]]などの[[オブジェクト]]がその外部に公開しているすべての操作の開始時と終了時に保証されるべき、オブジェクト毎に共通した性質。 | ||
コードを呼ぶ側が[[事前条件]]と[[不変条件]]を満たす義務を負うことで、呼ばれたコードはその条件が恒真であるとの前提を利益として得る。 | コードを呼ぶ側が[[事前条件]]と[[不変条件]]を満たす義務を負うことで、呼ばれたコードはその条件が恒真であるとの前提を利益として得る。 | ||
15行目: | 17行目: | ||
== 契約による設計をサポートする主な言語 == | == 契約による設計をサポートする主な言語 == | ||
− | + | ここに記載する[[プログラミング言語]]はあくまで一例でありすべてではない。 | |
− | === | + | === .NET Framework 4.0 === |
[[.NET Framework 4.0]]では、[[コードコントラクト]]([[Code Contracts]])という名前の機能が追加され、[[プログラミング言語]]レベルではなく、[[ランタイム]]レベルで「契約による設計」に対応した。これにより[[.NET Framework]]系のすべての[[プログラミング言語]]が対応することとなった。 | [[.NET Framework 4.0]]では、[[コードコントラクト]]([[Code Contracts]])という名前の機能が追加され、[[プログラミング言語]]レベルではなく、[[ランタイム]]レベルで「契約による設計」に対応した。これにより[[.NET Framework]]系のすべての[[プログラミング言語]]が対応することとなった。 | ||
− | + | また[[Visual Studio]]用のアドオンも提供されており、契約による設計のキモである[[静的チェック]]や[[ドキュメント]]の自動生成も行いえる。とくに[[静的チェック]]はとても重要な要素であり、これが使えないとただの[[コーディング規約]]程度の話で終わってしまい、契約による設計の魅力の99.9999%が失われる。なお[[アドオン]]が使えない[[Visual Studio Express]]ではツール群が使えないので、ただの実行時のエラーチェックと化し、前述のように契約による設計の魅力の99.9999%が失われる。 | |
− | [[コードコントラクト]] | + | [[コードコントラクト]]を利用するための[[ライブラリ]]は[[System.Diagnostics.Contracts 名前空間]]にあり、[[事前条件]]、[[事後条件]]、[[不変条件]]などの表すための[[C Sharp/静的クラス|静的クラス]]が用意されている。 |
* http://msdn.microsoft.com/en-us/devlabs/dd491992 | * http://msdn.microsoft.com/en-us/devlabs/dd491992 | ||
− | === [[D言語]] | + | === D言語 === |
+ | [[D言語]]の契約による設計機能は初の正式版リリースにあわせた目玉機能として大々的に宣伝されていた。 | ||
+ | しかし、プロジェクト自体のゴタゴタで正式リリースが遅れに遅れたことで[[.NET Framework 4.0]]に先を越されるという事態になった。 | ||
+ | 残念賞である。 | ||
− | === [[ | + | === Sather === |
− | [[Eiffel]] | + | [[Sather]]は[[Eiffel]]から派生した[[サブセット]]であり、その後に独自の進化を遂げてものらしい。 |
+ | まったく知らない。 | ||
− | === | + | === Eiffel === |
− | [[Eiffel]] | + | [[Eiffel]]は契約による設計を提唱およびサポートした一番最初の[[プログラミング言語]]だそうだ。 |
まったく知らない。 | まったく知らない。 | ||
+ | |||
+ | Eiffelの開発元であるEiffel Software(旧名:Interactive Software Engineering、略称:ISE)とマイクロソフト、オーストラリアのモナッシュ大学のグループが共同で[[共通言語ランタイム]]で動く[[Eiffel Sharp|Eiffel#]]なるものを出している<ref>[http://msdn.microsoft.com/ja-jp/library/ms973898.aspx</ref>。Eiffelの一部なので別途パッケージがあるわけではなく、[[Eiffel]]を入れるとオマケで付いてくる感じである。 | ||
== 関連項目 == | == 関連項目 == |
2014年8月7日 (木) 07:43時点における最新版
契約による設計(英語:Design By Contract、でざいん・ばい・こんとらくと)とは、ソースコードの中にプログラムが満たすべき仕様(契約)についての記述を盛り込み、設計の安全性を高めるプログラミングの技法のひとつ、またはプログラミング言語の機能のひとつである。
契約プログラミング(Programming By Contract)や、Design by Contract の頭文字であるDbC (でぃーびーしー) とよばれることもある。
目次
概要[編集 | ソースを編集]
たとえば、あるサブルーチンに引数があるとして、その引数がぬるぽやぬるりになることを防ぐためにサブルーチンの先頭部分でnullチェックや境界チェックを行う、などというコーディング規約に近いものを、プログラミング言語の仕様として半ば強制することで、静的コード解析やドキュメント生成、単体テスト(のテンプレート生成)などを的確かつ効率的に行えるようにし、プログラムの品質を向上させようというものである。
条件の種類[編集 | ソースを編集]
契約は、コードの利用条件が満たされることによって成立する。それら条件は、満たすべきタイミングと主体によって以下の3種類に分けられる。
- 事前条件 (precondition)
- サブルーチンの開始時に、これを呼ぶ側で保証すべき性質。たとえばというか、ほぼ引数の値のチェックである。
- 事後条件 (postcondition)
- サブルーチンが、終了時に保証すべき性質。たとえば「戻り値は絶対にnullを返さない」などを決めておくことを言う。
- 不変条件 (invariant)
- クラスなどのオブジェクトがその外部に公開しているすべての操作の開始時と終了時に保証されるべき、オブジェクト毎に共通した性質。
コードを呼ぶ側が事前条件と不変条件を満たす義務を負うことで、呼ばれたコードはその条件が恒真であるとの前提を利益として得る。
引き換えに、呼ばれたコードは事後条件と不変条件を義務として負い、呼ぶ側の利益としてこれを保証する。
契約による設計をサポートする主な言語[編集 | ソースを編集]
ここに記載するプログラミング言語はあくまで一例でありすべてではない。
.NET Framework 4.0[編集 | ソースを編集]
.NET Framework 4.0では、コードコントラクト(Code Contracts)という名前の機能が追加され、プログラミング言語レベルではなく、ランタイムレベルで「契約による設計」に対応した。これにより.NET Framework系のすべてのプログラミング言語が対応することとなった。
またVisual Studio用のアドオンも提供されており、契約による設計のキモである静的チェックやドキュメントの自動生成も行いえる。とくに静的チェックはとても重要な要素であり、これが使えないとただのコーディング規約程度の話で終わってしまい、契約による設計の魅力の99.9999%が失われる。なおアドオンが使えないVisual Studio Expressではツール群が使えないので、ただの実行時のエラーチェックと化し、前述のように契約による設計の魅力の99.9999%が失われる。
コードコントラクトを利用するためのライブラリはSystem.Diagnostics.Contracts 名前空間にあり、事前条件、事後条件、不変条件などの表すための静的クラスが用意されている。
D言語[編集 | ソースを編集]
D言語の契約による設計機能は初の正式版リリースにあわせた目玉機能として大々的に宣伝されていた。 しかし、プロジェクト自体のゴタゴタで正式リリースが遅れに遅れたことで.NET Framework 4.0に先を越されるという事態になった。 残念賞である。
Sather[編集 | ソースを編集]
SatherはEiffelから派生したサブセットであり、その後に独自の進化を遂げてものらしい。 まったく知らない。
Eiffel[編集 | ソースを編集]
Eiffelは契約による設計を提唱およびサポートした一番最初のプログラミング言語だそうだ。 まったく知らない。
Eiffelの開発元であるEiffel Software(旧名:Interactive Software Engineering、略称:ISE)とマイクロソフト、オーストラリアのモナッシュ大学のグループが共同で共通言語ランタイムで動くEiffel#なるものを出している[1]。Eiffelの一部なので別途パッケージがあるわけではなく、Eiffelを入れるとオマケで付いてくる感じである。
関連項目[編集 | ソースを編集]
- バートランド・メイヤー(仏:Bertrand Meyer) - 契約による設計の提唱者、Eiffelを作ったプログラマー
- リスコフの置換原則(Liskov substitution principle)
- 正当性(Correctness)
- 表明(Assertion)
- コーディング規約
- デザインパターン
- 設計
- 実装
- 仕様