11章 契約による設計：信頼性の高いソフトウェアを構築する
テーマ*
- 信頼性を確保するための手法として
- 「表明」の概念を説明
- キーコンセプトは「契約による設計」
- 例外処理は12章
この本の前の章の復習を交えて信頼性を構築するためのメカニズムを説明
- アーキテクチャ
- シンプル、モジュール性、拡張性
- 特に、モジュール間の疎結合
- エレガントで読みやすい物にする
- GC
- 静的型付け
正しさは相対的な概念である
- 正しいかどうかを論じるべきでは無い
- 仕様書と一致するかを論じるべき
仕様書を書くことが、正しい事を保証する第一歩*
ソフトウェアを書く時もしくは前に表明を書く*
- 初めから正しいプログラムが作れる
- 問題と起こりうる結果をよく理解できる
- ソフトウェアの文書化が容易になる
- 体型的なテスト・デバッグの基礎
正しさの公式
- ホーアのトリプルとも
- 事前条件・事後条件
弱い条件と強い条件
- より厳しい条件を「強い」と呼ぶ
- 形式論理学(記号論理学)用語とのこと
- 例
- {False} A {…} … 常に正しい
- {…} A {True} … 処理が終了すれば常に正しい
顧客モジュールと供給者モジュールのトレードオフ*
- 一方の利益はもう一方の義務となる
ソフトウェアの目的をソフトウェア自身に記述する
仕様として表明を利用する
- (この言語の表明構文の説明?)
- セミコロンを使った表記
- ラベル
例
- require と ensure 節
- old キーワード
事前条件/事後条件が満たさない場合は何が起こるのか?
- 後述する
- 何を望んでいるかによる
事前条件と事後条件の組み合わせ = 契約*
- 人間の社会における契約と同じ*
- 事前条件は顧客にとっては義務、提供者にとっては利益
- 事後条件は顧客にとっては利益、提供者にとっては義務
常識とは逆
事前条件は供給者にとっての利益
- プログラムを大きくシンプルにできる
- 事前条件を満たさないケースの検証をルーチンの中で行ってはいけない*
- (余談: 昔はどこまで入力チェックするべきか分からずに、空気を読んで入力チェックを大量に書いてたことを思い出しました…)
防衛的プログラミング*
- 自己防衛をする
- よく言われがちな方針
- 契約による設計とは逆
防衛的プログラミングの問題点*
-
狭い観点なら、足りないよりは過剰なテストが堅固になるようにみえる
-
巨視的に見ると「複雑さ」の元
- 検査の悪循環
- (継ぎ足し受け継がれる秘伝のソースコード…)
-
コストの増大につながる
-
ハードウェアでは外的要因でエラーが起こるので、冗長な検査は必要なので誤解なきよう…
代替案
- 顧客と供給者が協力して条件を見極める
- それぞれの条件を満たす責任がどちらにあるのかを明確化する
入力と事前条件
- 事前条件は入力の面倒を見ない
- 入力チェックモジュールを用意する
- 事前条件違反は顧客側のバグ
- 事後条件違反は供給者側のバグ
「バグ」の明確な用語
- エラー、欠陥、フォルト
- エラーから欠陥が生じ、フォルトは欠陥によって起こる
契約による設計はコストが高めになりそう
- 契約による設計にあったアーキテクチャとそうでないアーキテクチャがありそう
- アプリケーションレイヤーに近いと比較的費用対効果が薄そう
- 抽象レイヤーの境界(アプリケーションとモデル、汎用ライブラリなど)では効果的そう