おまいら、DbC（契約による設計）ってやってる？

何かと役に立ちそうなのに、ほとんど取り上げられてないよね


とりあえず参考URL
www.kmonos.net/alang/d/2.0/dbc.html
www.fides.dti.ne.jp/~oka-t/cpplab-dbc.html
www.02.246.ne.jp/~torutk/cxx/design/designbycontract.html

最近Dしか使ってないけどいちいち書いてないことが多い

大抵のPGは無意識にやってるだろうけど、
意識していないからメタメタになってるだけの気がする。

それゆえ軽視されがちだけど、一度は学んでおくべきだよな。

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

JavaだとJUnitとかあるから組み込みでは要らないんだよな。
入出力以外の部分でassert使うことはある。

真っ先に Eiffel を連想した。
取り敢えず EiffelEnvision ダウンロードしてみる。

…VS2003 必須だった。残念。

チームでの開発にはわりと必須だと思うんだがな
何で広まってないんだろう？

もっと盛りageれ

Eiffelしか知らないんだけど

>>8
まともに事前条件・事後条件を考えられるやつなんて少ないし、
書いてもまともに検証ができるわけじゃないから効果が薄い。
そして高コスト。広まるわけがない。

単体テストツールが普及してるからだろ。
システム開発でJUnitやNUnitを使わない連中は正気の沙汰とは思えん。

単体テストとDbCは同じことの違う表現なんだよな
単体テストが外延(のサブセット)でDbCは内包

>>11
全く同意。
うまくやるには予めなすべきことが全てみえてなければ
ならない。しかし、それができているならこんな手法を
取る必要もない。

>>11
>>14
そういうもんなのかねぇ。
コーディングしてるうちに自ずと見えてくると思うんだけどなぁ。
それに、クラスとかモジュール単位で考えたときに、提供する側と
利用する側でエラーの責任の所在を分離できるのは利点だと思うんだが。

明確な責任の委譲に役立つってことでOOPの肝となる概念として
Object-Oriented Software Construction(Mayer)で取り上げられてる

>>16
それ知らないヤツはこのスレ覗かないだろ

>>15
一度やってみるといいよ
事前条件は書けても事後条件が書けなくて悩むことになるから
事後条件が書けないってのは仕様をわかってないことと同義なんだけど
最初から仕様をきっちり把握するのがいかに難しいことかと痛感する
その上せっかく書いた事前・事後条件の正しさを証明するのは難しい

純粋関数型言語ならちょっとは楽に使えるというのを聞いたことがある

@preとかない分だけじゃね？＞ちょっとは楽
関数型言語を使えば形式的な思考ができるみたいな発想俺は嫌いだ
関数型言語を楽に使いこなせるようなやつならDbCも楽というなら御意

>>18
メソッド単位で細分化して考えればそんなに大変でもないと思うけどな＞仕様の把握
というか、そのメソッドで行うこと＝事後条件と考えてやってるんだが

関数の実行によって満たされる事後条件を構造規則で合成して
最終的に使用を満たす命題を作るだけの簡単なパズルです

>>21
思ってないでやってみれば？

>>23
実際にやってみての感想だよ

>>24
なんかサンプル貼ってよ

プログラム書いた本人が事前条件・事後条件書いても意味ないよね？

あ、事前条件は意味あるか。

どっちも意味あるだろ
なんで意味がないと思ったんだ？

プログラマが事後条件と思っていることが正しいかどうかが分からないのでは？
仕様決めた人なら、事後条件を正しく記述できる可能性はあるだろうけど。

そりゃ契約による"設計"じゃなくて形式仕様記述の話題じぇねーの？

そうかもな。>>26はxUnitなんかによる単体試験を念頭に置いてたんで。

テストファーストは契約プログラミングの範疇なのかねぇ。
インタフェースだけ書いて全てのテストが最初はNGになるように書くから。

単体テストつっても品質保証のテストと設計技法なTDDのテストは意味が違う
DbCは設計技法

利用者が事前条件を守れば(その時に限って)提供者は事後条件を守りますっていうのが
契約だから事前条件と事後条件は両方揃って意味がある
それが顧客の要求(システムの仕様)を満たすかどうかは別問題
validationとverificationを混同したらあかん

仕様が決まらず走り続けるプロジェクトでは中々やってられないんだよね。
納期はそのままだから、とりあえず動くものをってなってしまう。

まぁようはプロジェクト管理ができてないわけだけど。

>>5
契約の継承できるか？
オーバーロードされた関数間の契約の合成も

>>36
それむしろJavaのassertでできないｗ

え？どっち？
むしろってついてるから、できるのかできないのかわからないや

もちろんJUnitは勝手にはやってくれない
自分でがんがるしかない

だよね
だからあれは言語に組み込まないといけないんじゃない？

いや言語にassertあるし。j2sdk1.4(Java4)から。

だから、javaのassertでもできないわけだが
あれはCのasert並みであってDbCとは無関係
つかEiffelだって完全にはできてないんだぞ

C++だけどこんなんがあった
http://lists.boost.org/Archives/boost/2010/02/162325.php
しかし例題が
http://dbcpp.sourceforge.net/example/Crowl2006/vector/main.cpp
事前事後条件に埋もれて本体コードがみにくいぜ！

>>43のサンプル、カッコだらけで一瞬LISPかと思ったｗ
C++やJavaとか広く普及してる言語で簡潔に記述する方法が確立されてないのが、
DbCが広まらない原因なんじゃなかろうか

EiffelとかD言語位かね
Dbcを言語機能に組み込んでるの

>>44
こういうの考えたんだがどうよ

C#の例。属性を使って事前条件、事後条件を設定する。
Javaはアノテーションを使う。
public class AAA {
[return : IsNull]
public object GetData([IsNull] string key){
...
}
}

あほだ・・・IsNullじゃなくてIsNotNullね

契約プログラミングってassertすれば良いの？

それは実現するための手段のひとつであって
他にはアレとかソレとかあるに違いないよ

というより、assertは契約違反を通知するための手段のうちで、
契約の内容がマニュアルだかソースのコメントだかに記載されてさえいれば
それでDbCの本懐は果たしてると言えるんじゃないかと

マニュアルやコメントじゃ契約違反を自動検知できないじゃん

契約プログラミングってどういう歴史なんだ？
assertのほうが先にあったの？それとも契約プログラミングの概念が出てからassertが出てきた？

Eiffel が1985年
ANSI Cは1989年だな。assertマクロがいつごろから使われていたかは知らん。

これをやってみようと思ったんだが、事前条件に依存した記述が
呼ばれる側、呼ぶ側、ユニットテスト、間接的に依存する所と、
散らばって悲惨なことに。どうすりゃきれいに行くんだろうか

eiffelよりsatherがいい。