Herkunft

Design by Contract ist ein Konzept von Bertrand Meyer, das er in seiner Programmiersprache Eiffel und der dazugehörigen Entwicklungs-Methode dargestellt hat.

Grundidee

Die Grundidee ist, eine Methode eines Objektes wie einen Lieferanten (supplier) und den Aufrufer wie einen Kunden (client) zu betrachten. Der Lieferant schließt mit dem Kunden einen Vertrag (contract): Wenn Du (Kunde) meine Anforderungen (in Gestalt von Vorbedingungen) einhältst, werde ich meine Zusicherungen (in Gestalt von Nachbedingungen) einhalten und im übrigen das gewünschte Verfahren durchführen. Sollte ich nicht in der Lage sein, das Verfahren durchzuführen, werde ich nicht "irgend etwas" liefern, sondern eine Ausnahme auslösen.

Zusätzlich gibt es noch sogenannte Invarianten. Diese kann man als spezielle Nachbedingungen betrachten, die immer zugesichert sind, wenn der Kontrollfluss an den client zurückgegeben wird.

Beispiel

Das Einfügen eines Elementes in ein Verzeichnis, und zwar unter einem bestimmten Schlüssel:

  put (x: ELEMENT; key: STRING) is
             -- Insert x so that it will be retrievable through key.
             require
                     count <= capacity
                     not key.empty
             do
                     ... Some insertion algorithm ...
             ensure
                     has (x)
                     item (key) = x
                     count = old count + 1
             end

• Die Kapazität des Verzeichnisses darf noch nicht erschöpft sein.
• Der Schlüssel darf nicht leer sein.

Die Zusicherungen sind:

• Das Verzeichnis hat ab sofort "x" als Eintrag.
• Das Item, das zu dem Schlüssel "key" gehört, ist "x".
• Die neue Anzahl der Einträge ist um 1 höher als die alte Anzahl.

Vererbung

Besonders mächtig wird DesignByContract im Zusammenspiel mit Vererbungshierarchien. Standardmäßig werden alle Bedingungen vollständig mitvererbt; sie können unter Einhaltung folgender Regeln aber durch Subklassen modifiziert werden:

• Vorbedingungen dürfen nicht verschärft, sondern nur aufgeweicht werden.
• Nachbedingungen (und Invarianten) dürfen nicht aufgeweicht, sondern nur verschärft werden.

Auf diese Art und Weise kann sogar der Contract eines Interfaces mehr oder weniger genau spezifiziert werden, ohne das also irgendetwas über die tatsächliche Implementierung bekannt ist. Dem Client ist damit sichergestellt, dass jede Implementierung diesem Contract genügt.

Anwendung

Man kann Vorbedingungen beim Eintritt in die Methode mit Hilfe von Asserts abprüfen und eine Ausnahme auslösen, wenn sie nicht eingehalten sind.

Man kann Nachbedingungen beim Austritt aus der Methode mit Hilfe von Asserts abprüfen und eine Ausnahme auslösen, wenn sie nicht eingehalten sind.

Beides zusammen liefert recht robuste Software, da der Aufrufer der Methode sich rechtzeitig die Finger verbrennt, wenn er gegen den Vertrag verstößt, den die Methode fordert.

Das Ganze ist natürlich nicht kostenlos! :-)

Diskussion

Sollte ich nicht in der Lage sein, das Verfahren durchzuführen, werde ich nicht "irgend etwas" liefern, sondern eine Ausnahme auslösen.

Nein, es ist ganz wichtig, dass eine Exception fliegt. Ein undefiniertes Ergebnis würde Design by contract entscheidend schwächen. Die Robustheit kommt ja gerade daher, dass sich der Aufrufer darauf verlassen kann, entweder das zugesicherte Ergebnis zu bekommen oder aber ganz deutlich zu merken, dass er es NICHT bekommt. -- MatthiasBohlen

Ressourcen

• iContract - The Java(tm) Design by Contract(tm) Tool

siehe auch:

• WardsWiki:DesignByContract
• AbgrenzungTestenZuAssertZuDesignByContract
• IstAssertSinnvoll
• AssertionVermeidung
• Design by Contract in SpracheLava
• "Industriell entwickeln durch Contract First Design", Ralf Westphal, iX 8/2006, S.44-52.
• Contract First Design (CFD) und "Microkernel-Architektur" nach Ralf Westphal, bei Microsoft downloadbarer WebCast (8.5MB)