目次

契約による設計

  • =Design by Contact
    • DbCと略する。
  • 『オブジェクト指向入門』(アスキー刊)*1でBertrand Meyerが紹介した。
  • インタフェースはそのインタフェースのユーザーとの契約を持っているというもの。
  • 契約はインタフェース内のすべてのメソッド内の事前条件・不変条件・事後条件で構成される。
  • 契約はクラスのコードや関連する文書内で明白にすべきである。
    • 例えば、JavaDocに注意深く契約を記述したとしても、自然言語ではあいまいさは完全に排除できない。
      • Eiffelで契約を明確にできるが、Javaではこの機能は組み込まれていない。
      • Contract4J5はJava向けのアスペクト志向プログラミング拡張であるAspectJを使って契約が守られているかどうかをチェックする。
  • 契約をチェックするには、通常のif文など、アサーション、アスペクト、言語固有の機能などを使う。
  • DbCを使うとプログラム開発時のバグを早期に発見することが可能になる。
  • DbCの考えにしたがい仕様を明確にすると、その仕様に対するテストを定義しやすくなる。

DbCの3つの条件

  • DbCでは事前条件・事後条件・不変条件の3つを明確に定義する必要がある。

事前条件(precondition)

  • メソッドが操作を実行できるようにするために、メソッドが呼び出されたときに真でなければならない条件のこと。

[例]

  • 引数は正の実数のみ。
  • 引数はnullは許さない。

不変条件(invariant)

  • 不変条件とは有効なオブジェクトに対して常に真である必要がある条件のことである。
  • 不変条件が満たすことができなかった場合、それはオブジェクトに内在するバグとして扱われる。

[例]

  • 属性の値が常に2つの値の間になければならない。
  • プロパティnameはnullになることはない。

事後条件(postcondition)

  • 事後条件とはメソッドが完了したときに真であるべき条件である。

[例]

  • 引数の平方根を返す。

参考文献

  • 『エンジニアのためのJavadoc再入門講座』
  • 『プレリファクタリング』


*1 洋書は『The Enterprise Unified Process: Extending the Rational Unified Process』(Prentice Hall)。