契約プログラミング
サブクラスのインスタンスの振る舞いは前述の通りサブクラス自身の不変条件および各メソッドの事前条件と事後条件によって定義されるが、一方でサブクラスのインスタンスはクライアントと継承元のスーパークラスの契約に拘束され、スーパークラスのインスタンスとしても振る舞えなければならない(リスコフの置換原則)。 したがって、クライアントと継承元のスーパークラスの間の契約を実現するため、サブクラスはスーパークラスの不変条件を常に満たさなければならず(したがってサブクラスの不変条件は自身の不変条件とすべてのスーパークラスの不変条件の論理積となる)、またサブクラスの事前条件はスーパークラスの事前条件より弱く(または等しく)、サブクラスの事後条件はスーパークラスの事後条件より強く(または等しく)なければならない。
ここで、「条件 A が条件 B より強い」とは、A が成り立つなら B も必ず成り立ち、逆は成り立たないことを言う。例えば、実数 x に対して x > 2 が成り立つなら常に x > 0 が成り立つが、逆は成り立たない。この場合、実数 x に対する条件 x > 2 は条件 x > 0 より強い、と言える。他方「条件 A が条件 B より弱い」とは、B が A より強いことを指す。
このクライアントとサプライヤの双方に生じる義務と、義務を守った際に保証された状態を得られる利益とが現れる点で、プログラミングにおける「契約」と一般的な意味での契約の類似を見出せる。
表明を予め記述しておくことで、実装者はその表明に従ってプログラムを記述することができる。一般に表明は静的な記述であり、必ずしもプログラム動作時に意味を持つものではないが、DbC をサポートするプログラミング言語では、プログラム実行時に表明を違反していないか監視することができる。実行時の表明違反の監視に関連して、例外機構を利用することにより、実行時の表明違反を例外としてクライアントに処理させることができる。
クラス A が、クラス B に関するエンティティ(ローカル変数の定義やメソッド呼び出し)の記述を含む場合、B は A に対するサプライヤ、A は B に対するクライアントとなる。クライアントとサプライヤは同一クラスであってもよく、例えば this を介したメソッド呼び出しが相当する。