アサーションを正しいソフトウェアを書く道具として使う

前回説明したようにassert文を使えば正しいソフトウェアを書く手助けになる。これはassert文の最も重要な使命だ。

ある重要な原則がある。すなわち「契約による設計」の原則である。

あるメソッドを呼び出すということはあるサービスを受ける契約を結ぶということである。良い契約とは当事者其々の権利と責任、そしてその限界を明確に取り決める事である。assert文はこれら取り決めにより何が期待できて何が保証されるかを厳密に述べる手段を両当事者に提供する。

契約が守られなかった場合、メソッドはAssertionErrorをスローする。原因は常にバグである。試験中なら即時システムをダウンし原因を追及すべきである。稼働中ならどう対処すべきかは状況による。そのためassert文はオプションとしてOnOff切り替えが可能という仕組みとなっている。

さて、AssertionErrorが起きた場合の対応は２つしかない。呼び出し側の対応を変えるかメソッド側の対応を変えるかである。

呼び出し側の対応を変えるというのは事前条件を変えないという事である。if文などを使い事前条件に合致しないケースではメソッド呼び出しをしないことを徹底する。

一方メソッド側の対応を変えるというのは事前条件を拡張するということである。勿論事前条件が拡張されても事後条件はそのままか更に厳しい条件でなければならない。事前条件を拡張したからと云って事後条件まで拡張すればこれまで動いていたプログラムまで破綻しかねない。