237 名前： デフォルトの名無しさん [sage] 投稿日： 03/02/27 07:42
assertionを記述することは、デバッグにおける
原因探索の無駄を省くとは思うが、「コード化」
だけを考えたら、直接の御利益はないかもね。

とはいえ、バグっても人が死なないシステムなら
ゴメンナサイとか謝っちまえばいいのか（笑）
238 名前： デフォルトの名無しさん [sage] 投稿日： 03/03/03 13:17
Design by Contract (DbC) 周りで、
制約条件をOCLで記述する iContract が流行っているらしい。(JavaWorldで既出)

単なるassertionだけでなく、実装コードを埋め尽くすつまんない条件分けコード
を一掃するのに使えれば、いいのかな？


239 名前： デフォルトの名無しさん [sage] 投稿日： 03/03/03 13:44
iContract、AspectJ (@www.eclipse.org) に組み込んで使えるらしい。
下のFAQによると、複数のクラスにまたがるinvariants(invariants cross-cutting)
を扱えるようになるのがメリットらしい。
　http://www.reliable-systems.com/tools/iContract/FAQ.htm

個人的には、複数のAspect間の干渉を排除するヒント情報として活用できたらいいと思った