Index: [Article Count Order] [Thread]

Date:  Sun, 08 Sep 2002 17:30:18 +0900
From:  "Nakajima Katsuyuki" <****************@*******.***>
Subject:  [oosquare-ml:02974] Re: DbC の落とし穴?
To:  ***********@***.***.*******.**.**
Message-Id:  <***************************@*******.***>
X-Mail-Count: 02974

中島です。

> 4) 失敗したらどうする?
> 
> 出荷時に表明を取り去るのは,「ライフジャケットを付けてプール
> で練習し,ライフジャケットを脱いで海で泳ぐようなもの」,と誰
> かが言っていました.アプリケーションに求められる品質と環境に
> もよりますが,場合によっては,再上位のエラー処理方針や,別立
> てのエラー監視ポリシー(アプリケーション異常終了時のロギング
> や再起動など)を策定する必要がある.
一番、経験値が必要そうなところですね。
ネックになりそう・・・。

> 5) 内部表明と外部表明
> 
> XP のユニットテスティングに代表されるような,クラス外部から
> の asserting と,DbC のようなコード内部の asserting をどうす
> るか.すべて外部,すべて内部,あるいは,バランスさせる.
内部表明が必要条件で外部表明が必要十分条件という事なのでしょう
か。マニュアルに2種類の条件を記述するのも確かに面倒ですね。
これも、経験値がないと難しそうですね。

> (2) 表明はインターフェイスに書きたいのに実装に記述するしかない
> 
> 表明は仕様をコードとして記述するものであり,仕様はインターフェイスの一部
> だと思います.ですから,本当はインターフェイス(純粋仮想関数,abstract 
> メソッド)に表明を書きたいのですが,言語の制約上実装部分に記述するしかあ
> りません.(私の使用言語は C++ です)
設計者用のクラスを作ればいいという事でしょうか。
そんなのがあればいいですね。

導入・運用は簡単ではないというのがわかりました。
でも、DbCは「やらないよりはまし」という寺田さんの意見に同意してみたいので
皆さんの意見を参考にして、まずは導入調査からはじめたいと思います。

ご意見ありがとうございます。


_________________________________________________________________
最新のファイナンス情報とライフプランのアドバイス MSN マネー 
http://money.msn.co.jp/