トップページ⇒tech
55コメント13KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/02/09(火) 13:51:55
何かと役に立ちそうなのに、ほとんど取り上げられてないよね


とりあえず参考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
0002デフォルトの名無しさん2010/02/09(火) 21:12:19
最近Dしか使ってないけどいちいち書いてないことが多い
0003デフォルトの名無しさん2010/02/09(火) 21:28:05
大抵のPGは無意識にやってるだろうけど、
意識していないからメタメタになってるだけの気がする。

それゆえ軽視されがちだけど、一度は学んでおくべきだよな。
0004デフォルトの名無しさん2010/02/09(火) 22:15:37
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
0005デフォルトの名無しさん2010/02/10(水) 08:06:14
JavaだとJUnitとかあるから組み込みでは要らないんだよな。
入出力以外の部分でassert使うことはある。
0006デフォルトの名無しさん2010/02/11(木) 02:59:08
真っ先に Eiffel を連想した。
取り敢えず EiffelEnvision ダウンロードしてみる。
000762010/02/11(木) 04:22:30
…VS2003 必須だった。残念。
0008デフォルトの名無しさん2010/02/11(木) 09:37:47
チームでの開発にはわりと必須だと思うんだがな
何で広まってないんだろう？
0009デフォルトの名無しさん2010/02/12(金) 09:54:38
もっと盛りageれ
0010デフォルトの名無しさん2010/02/12(金) 10:01:56
Eiffelしか知らないんだけど
0011デフォルトの名無しさん2010/02/12(金) 21:51:42
>>8
まともに事前条件・事後条件を考えられるやつなんて少ないし、
書いてもまともに検証ができるわけじゃないから効果が薄い。
そして高コスト。広まるわけがない。
0012デフォルトの名無しさん2010/02/12(金) 22:14:00
単体テストツールが普及してるからだろ。
システム開発でJUnitやNUnitを使わない連中は正気の沙汰とは思えん。
0013デフォルトの名無しさん2010/02/12(金) 22:45:40
単体テストとDbCは同じことの違う表現なんだよな
単体テストが外延(のサブセット)でDbCは内包
0014デフォルトの名無しさん2010/02/13(土) 12:15:40
>>11
全く同意。
うまくやるには予めなすべきことが全てみえてなければ
ならない。しかし、それができているならこんな手法を
取る必要もない。
0015デフォルトの名無しさん2010/02/13(土) 12:43:28
>>11
>>14
そういうもんなのかねぇ。
コーディングしてるうちに自ずと見えてくると思うんだけどなぁ。
それに、クラスとかモジュール単位で考えたときに、提供する側と
利用する側でエラーの責任の所在を分離できるのは利点だと思うんだが。
0016デフォルトの名無しさん2010/02/13(土) 12:49:31
明確な責任の委譲に役立つってことでOOPの肝となる概念として
Object-Oriented Software Construction(Mayer)で取り上げられてる
0017デフォルトの名無しさん2010/02/13(土) 13:00:27
>>16
それ知らないヤツはこのスレ覗かないだろ
0018デフォルトの名無しさん2010/02/13(土) 13:10:28
>>15
一度やってみるといいよ
事前条件は書けても事後条件が書けなくて悩むことになるから
事後条件が書けないってのは仕様をわかってないことと同義なんだけど
最初から仕様をきっちり把握するのがいかに難しいことかと痛感する
その上せっかく書いた事前・事後条件の正しさを証明するのは難しい
0019デフォルトの名無しさん2010/02/13(土) 13:25:20
純粋関数型言語ならちょっとは楽に使えるというのを聞いたことがある
0020デフォルトの名無しさん2010/02/13(土) 13:43:56
@preとかない分だけじゃね？＞ちょっとは楽
関数型言語を使えば形式的な思考ができるみたいな発想俺は嫌いだ
関数型言語を楽に使いこなせるようなやつならDbCも楽というなら御意
0021デフォルトの名無しさん2010/02/13(土) 14:24:27
>>18
メソッド単位で細分化して考えればそんなに大変でもないと思うけどな＞仕様の把握
というか、そのメソッドで行うこと＝事後条件と考えてやってるんだが
0022デフォルトの名無しさん2010/02/13(土) 14:26:41
関数の実行によって満たされる事後条件を構造規則で合成して
最終的に使用を満たす命題を作るだけの簡単なパズルです
0023デフォルトの名無しさん2010/02/13(土) 15:49:31
>>21
思ってないでやってみれば？
0024デフォルトの名無しさん2010/02/13(土) 16:36:58
>>23
実際にやってみての感想だよ
0025デフォルトの名無しさん2010/02/13(土) 17:02:27
>>24
なんかサンプル貼ってよ
0026デフォルトの名無しさん2010/02/13(土) 17:08:19
プログラム書いた本人が事前条件・事後条件書いても意味ないよね？
0027262010/02/13(土) 17:09:02
あ、事前条件は意味あるか。
0028デフォルトの名無しさん2010/02/13(土) 17:15:54
どっちも意味あるだろ
なんで意味がないと思ったんだ？
0029デフォルトの名無しさん2010/02/13(土) 17:25:20
プログラマが事後条件と思っていることが正しいかどうかが分からないのでは？
仕様決めた人なら、事後条件を正しく記述できる可能性はあるだろうけど。
0030デフォルトの名無しさん2010/02/13(土) 17:30:58
そりゃ契約による"設計"じゃなくて形式仕様記述の話題じぇねーの？
0031デフォルトの名無しさん2010/02/13(土) 17:39:55
そうかもな。>>26はxUnitなんかによる単体試験を念頭に置いてたんで。
0032デフォルトの名無しさん2010/02/13(土) 17:44:33
テストファーストは契約プログラミングの範疇なのかねぇ。
インタフェースだけ書いて全てのテストが最初はNGになるように書くから。
0033デフォルトの名無しさん2010/02/13(土) 17:46:13
単体テストつっても品質保証のテストと設計技法なTDDのテストは意味が違う
DbCは設計技法
0034デフォルトの名無しさん2010/02/13(土) 17:49:34
利用者が事前条件を守れば(その時に限って)提供者は事後条件を守りますっていうのが
契約だから事前条件と事後条件は両方揃って意味がある
それが顧客の要求(システムの仕様)を満たすかどうかは別問題
validationとverificationを混同したらあかん
0035デフォルトの名無しさん2010/02/13(土) 19:45:41
仕様が決まらず走り続けるプロジェクトでは中々やってられないんだよね。
納期はそのままだから、とりあえず動くものをってなってしまう。

まぁようはプロジェクト管理ができてないわけだけど。
0036デフォルトの名無しさん2010/02/14(日) 11:24:26
>>5
契約の継承できるか？
オーバーロードされた関数間の契約の合成も
0037デフォルトの名無しさん2010/02/14(日) 11:33:45
>>36
それむしろJavaのassertでできないｗ
0038デフォルトの名無しさん2010/02/14(日) 18:06:00
え？どっち？
むしろってついてるから、できるのかできないのかわからないや
0039デフォルトの名無しさん2010/02/14(日) 18:56:08
もちろんJUnitは勝手にはやってくれない
自分でがんがるしかない
0040デフォルトの名無しさん2010/02/16(火) 03:58:03
だよね
だからあれは言語に組み込まないといけないんじゃない？
0041デフォルトの名無しさん2010/02/16(火) 04:21:48
いや言語にassertあるし。j2sdk1.4(Java4)から。
0042デフォルトの名無しさん2010/02/16(火) 12:34:11
だから、javaのassertでもできないわけだが
あれはCのasert並みであってDbCとは無関係
つかEiffelだって完全にはできてないんだぞ
0043デフォルトの名無しさん2010/03/02(火) 22:58:12
C++だけどこんなんがあった
http://lists.boost.org/Archives/boost/2010/02/162325.php
しかし例題が
http://dbcpp.sourceforge.net/example/Crowl2006/vector/main.cpp
事前事後条件に埋もれて本体コードがみにくいぜ！
0044デフォルトの名無しさん2010/03/09(火) 19:21:51
>>43のサンプル、カッコだらけで一瞬LISPかと思ったｗ
C++やJavaとか広く普及してる言語で簡潔に記述する方法が確立されてないのが、
DbCが広まらない原因なんじゃなかろうか
0045デフォルトの名無しさん2010/03/17(水) 21:31:27
EiffelとかD言語位かね
Dbcを言語機能に組み込んでるの
0046デフォルトの名無しさん2010/05/18(火) 00:17:48
>>44
こういうの考えたんだがどうよ

C#の例。属性を使って事前条件、事後条件を設定する。
Javaはアノテーションを使う。
public class AAA {
[return : IsNull]
public object GetData([IsNull] string key){
...
}
}
0047462010/05/18(火) 00:20:08
あほだ・・・IsNullじゃなくてIsNotNullね
0048デフォルトの名無しさん2010/09/05(日) 13:59:29
契約プログラミングってassertすれば良いの？
0049デフォルトの名無しさん2010/10/23(土) 10:53:31
それは実現するための手段のひとつであって
他にはアレとかソレとかあるに違いないよ
0050デフォルトの名無しさん2010/12/18(土) 10:44:16
というより、assertは契約違反を通知するための手段のうちで、
契約の内容がマニュアルだかソースのコメントだかに記載されてさえいれば
それでDbCの本懐は果たしてると言えるんじゃないかと
0051デフォルトの名無しさん2010/12/18(土) 11:53:27
マニュアルやコメントじゃ契約違反を自動検知できないじゃん
0052デフォルトの名無しさん2011/08/31(水) 02:10:21.48
契約プログラミングってどういう歴史なんだ？
assertのほうが先にあったの？それとも契約プログラミングの概念が出てからassertが出てきた？
0053デフォルトの名無しさん2011/08/31(水) 08:50:02.78
Eiffel が1985年
ANSI Cは1989年だな。assertマクロがいつごろから使われていたかは知らん。
0054デフォルトの名無しさん2011/10/24(月) 19:44:08.90
これをやってみようと思ったんだが、事前条件に依存した記述が
呼ばれる側、呼ぶ側、ユニットテスト、間接的に依存する所と、
散らばって悲惨なことに。どうすりゃきれいに行くんだろうか
0055デフォルトの名無しさん2012/05/18(金) 23:10:10.10
eiffelよりsatherがいい。
■ このスレッドは過去ログ倉庫に格納されています