インスタンスの状態に関する事前条件の例として、スタックから要素を取り出す操作(pop)に関して、クライアントは対象のスタックが空でないことを保証する必要があることが挙げられる(スタックが空の場合に何らかの値を返すことを認めない場合)。事前条件をクライアントとサプライヤの間の契約と見なせば、事前条件を満たすことはクライアントの義務に相当し、事前条件が満たされている前提でメソッド本体を設計できることはサプライヤが受ける利益に相当する。またクライアントに事前条件を提示することは、クライアントとサプライヤの間で責任の所在がどちらにあるのかを明らかにすることつながる。事前条件に対する検査をクライアントが行うよう責任分担することで、サプライヤ側で冗長な検査を行うことや、逆に全く検査が行われないことを避けることができる。事前条件は表明の一種であり、コンパイル時やプログラム実行時に検査することが可能である(詳細な仕様はプログラミング言語ごとに異なる)。事後条件.事後条件()は、メソッド正常終了時に保証されるべき条件の表明である。これはメソッド単位で表明される。正常終了とは、例外スロー終了やエラー発生終了ではないことを指す。具体的には以下になる。事後条件を満たすことはサプライヤの義務になり、もし満たされた場合は事前に決められた状態遷移が果たされて、これはクライアントの利益になる。クライアントは事後条件への作業から解放される。不変条件.クラス不変条件()は、クラスが持つ公開された各メソッドの開始時と正常終了時に共通して保証されるべき状態についての条件である。ただしコンストラクタの呼び出しに関しては、事後条件としてのみ適用され事前条件として保証する必要はない。(引数や返り値などを制約するメソッド個別の事前/事後条件と異なり)不変条件はインスタンスの状態にのみに対する表明である。インスタンスの「状態」はそのインスタンスのすべてフィールドの値によって決まるため、より具体的には、不変条件はフィールドの値に関する表明となる。不変条件は公開メソッドの事前条件および事後条件として暗黙的に追加される。不変条件を持つクラスに関して、そのクラスの公開メソッドの呼び出しの際、クライアントはメソッドの事前条件とサプライヤ・クラスの不変条件の両方を満たす義務がある。