Funktioniert Design by Contract für Sie?[geschlossen]

StackOverflow https://stackoverflow.com/questions/26455

  •  09-06-2019
  •  | 
  •  

Frage

Nutzen Sie Design by Contract beruflich?Müssen Sie dies gleich zu Beginn eines Projekts tun, oder können Sie einen anderen Gang einlegen und damit beginnen, es in Ihren Softwareentwicklungslebenszyklus zu integrieren?Was sind Ihrer Meinung nach die Vor- und Nachteile des Designansatzes?

Ich bin auf das gestoßen Entwurf nach Vertrag Ansatz in einem Graduiertenschulkurs.Im akademischen Umfeld schien es eine ziemlich nützliche Technik zu sein.Aber ich verwende Design by Contract derzeit nicht professionell und kenne keinen anderen Entwickler, der es verwendet.Es wäre gut, von der SO-Community etwas über die tatsächliche Verwendung zu erfahren.

War es hilfreich?

Lösung

Ich kann es nicht genug empfehlen.Es ist besonders schön, wenn Sie über eine Suite verfügen, die Vertragsspezifikationen für die Inline-Dokumentation übernimmt, etwa so:

// @returns null iff x = 0
public foo(int x) {
  ...
}

und wandelt sie in generierte Unit-Tests um, etwa so:

public test_foo_returns_null_iff_x_equals_0() {
  assertNull foo(0);
}

Auf diese Weise können Sie die von Ihnen ausgeführten Tests tatsächlich sehen, sie werden jedoch automatisch generiert.Generierte Tests sollten übrigens nicht in die Quellcodeverwaltung eingecheckt werden.

Andere Tipps

Sie können Design by Contract wirklich zu schätzen wissen, wenn Sie eine Schnittstelle zwischen zwei Anwendungen haben, die miteinander kommunizieren müssen.

Ohne Verträge wird diese Situation schnell zu einem Schuld-Tennisspiel.Die Teams werfen ständig Vorwürfe hin und her und es wird viel Zeit verschwendet.

Bei einem Vertrag ist die Schuld klar.

Hat der Anrufer die Voraussetzungen erfüllt?Wenn nicht, muss das Kundenteam das Problem beheben.

Hat der Empfänger bei einer gültigen Anfrage die Postbedingungen erfüllt?Wenn nicht, muss das Serverteam das Problem beheben.

Haben sich beide Parteien an den Vertrag gehalten, das Ergebnis ist jedoch unbefriedigend?Der Vertrag ist unzureichend und das Problem muss eskaliert werden.

Hierzu müssen Sie die Verträge nicht in Form von Geltendmachungen umsetzen lassen, sondern lediglich sicherstellen, dass sie dokumentiert und von allen Parteien vereinbart werden.

Wenn Sie sich STL, Boost, MFC, ATL und viele Open-Source-Projekte ansehen, können Sie sehen, dass es so viele ASSERTION-Anweisungen gibt, und das macht die Weiterentwicklung des Projekts sicherer.

Design-By-Contract!Es funktioniert wirklich in einem echten Produkt.

Frank Krüger schreibt:

Gaius:Eine Nullzeiger-Ausnahme wird von der Laufzeit automatisch für Sie ausgelöst. Es hat keinen Vorteil, diese Dinge im Funktionsprolog zu testen.

Ich habe zwei Antworten darauf:

  1. Null war nur ein Beispiel.Für Quadrat(x) möchte ich testen, ob die Quadratwurzel des Ergebnisses (ungefähr) dem Wert des Parameters entspricht.Für Setter möchte ich testen, ob sich der Wert tatsächlich geändert hat.Bei atomaren Operationen möchte ich überprüfen, ob alle Komponentenoperationen erfolgreich waren oder alle fehlgeschlagen sind (eigentlich ein Test auf Erfolg und n Tests auf Fehler).Bei Factory-Methoden in schwach typisierten Sprachen möchte ich überprüfen, ob der richtige Objekttyp zurückgegeben wird.Die Liste geht weiter und weiter.Grundsätzlich ist alles, was in einer Codezeile getestet werden kann, ein sehr guter Kandidat für einen Codevertrag in einem Prolog-Kommentar.

  2. Ich bin nicht der Meinung, dass man Dinge nicht testen sollte, weil sie Laufzeitausnahmen generieren.Wenn überhaupt, Sie sollen Testen Sie Dinge, die Laufzeitausnahmen generieren könnten.Ich mag Laufzeitausnahmen, weil sie das System verändern scheitern schnell, was beim Debuggen hilft.Aber die null Im Beispiel handelte es sich um einen Ergebniswert für eine mögliche Eingabe.Es gibt ein Argument dafür, niemals zurückzukehren null, aber wenn Sie es möchten, sollten Sie es testen.

Es ist absolut dumm, nicht auf Grundlage eines Vertrags zu entwerfen, wenn man irgendetwas in einem SOA-Bereich tut, und es ist immer hilfreich, wenn man an irgendeiner Art von modularer Arbeit arbeitet, bei der Teile und Teile später ausgetauscht werden könnten, insbesondere wenn es um Black Boxes geht .

Anstelle ausdrucksstärkerer Schriftsysteme würde ich bei militärischen Projekten unbedingt „Design by Contract“ verwenden.

Für schwach typisierte Sprachen oder Sprachen mit dynamischem Geltungsbereich (PHP, JavaScript) sind funktionale Verträge ebenfalls sehr praktisch.

Für alles andere würde ich es beiseite legen und mich auf Betatester und Unit-Tests verlassen.

Gaius:Eine Nullzeiger-Ausnahme wird von der Laufzeit automatisch für Sie ausgelöst. Es hat keinen Vorteil, diese Dinge im Funktionsprolog zu testen.Wenn Sie mehr an Dokumentation interessiert sind, würde ich Annotationen verwenden, die mit statischen Analysatoren und dergleichen verwendet werden können (um beispielsweise sicherzustellen, dass der Code Ihre Annotationen nicht beschädigt).

Ein stärkeres Schriftsystem in Verbindung mit Design by Contract scheint der richtige Weg zu sein.Schauen Sie mal rein Spezifikation# zum Beispiel:

Die Spec#-Programmiersprache.Spec# ist eine Erweiterung der objektorientierten Sprache C#.Es erweitert das Typsystem um Nichtnull-Typen und überprüfte Ausnahmen.Es bietet Methodenverträge in Form von Vor- und Nachschlägen sowie Objektinvarianten.

Sowohl Unit-Tests als auch Design by Contract sind meiner Erfahrung nach wertvolle Testansätze.

Ich habe versucht, „Design by Contract“ in einem Framework für automatische Systemtests zu verwenden, und meine Erfahrung zeigt, dass es eine Flexibilität und Möglichkeiten bietet, die durch Unit-Tests nicht einfach zu erreichen sind.Zum Beispiel ist es möglich, eine längere Sequenz auszuführen und zu überprüfen, ob die Antwortenzeiten jedes Mal innerhalb von Grenzen liegen, wenn eine Aktion ausgeführt wird.

Ein Blick auf die Präsentationen bei InfoQ zeigt, dass Design by Contract eine wertvolle Ergänzung zu den herkömmlichen Unit-Tests in der Integrationsphase von Komponenten darstellt.Zum Beispiel möglich, zuerst eine Scheinschnittstelle zu erstellen und dann die Komponente nach oder zu verwenden, wenn eine neue Version einer Komponente veröffentlicht wird.

Ich habe kein Toolkit gefunden, das meine gesamte Designanforderung für das Design durch Vertragstests auf der Plattform .NET/Microsoft abdeckt.

Eigentlich verwende ich Design by Contract nicht täglich.Ich weiß jedoch, dass es in die integriert wurde D Sprache, als Teil der Sprache.

Ja tut es!Tatsächlich habe ich vor ein paar Jahren ein kleines Framework für die Argumentvalidierung entworfen.Ich habe ein SOA-Projekt durchgeführt, bei dem die verschiedenen Back-End-Systeme alle Arten von Validierungen und Prüfungen durchführten.Um jedoch die Antwortzeiten zu erhöhen (in Fällen, in denen die Eingabe ungültig war, und um die Belastung dieser Back-End-Systeme zu verringern), haben wir begonnen, die Eingabeparameter der bereitgestellten Dienste zu validieren.Nicht nur für Not Null, sondern auch für String-Muster.Oder Werte aus Mengen.Und auch die Fälle, in denen Parameter Abhängigkeiten zwischen ihnen hatten.

Jetzt wird mir klar, dass wir damals ein kleines Design-by-Contract-Framework implementiert haben :)

Hier ist der Link für alle, die sich für das Kleine interessieren Validierung von Java-Argumenten Rahmen.Welches als einfache Java-Lösung implementiert ist.

Ich finde es bezeichnend, dass die Programmiersprache Go keine Konstrukte hat, die Design by Contract ermöglichen.Panik/Verzögerung/Wiederherstellen sind nicht genau das, da die Verzögerungs- und Wiederherstellungslogik es ermöglicht, Panik zu ignorieren und gebrochene Verträge zu ignorieren.Was zumindest benötigt wird, ist eine Form unwiederbringlicher Panik, und das ist wirklich der Fall.Oder bestenfalls direkte Sprachunterstützung des Designs durch Vertragskonstrukte (Vor- und Nachbedingungen, Implementierung und Klasseninvarianten).Aber angesichts der Eigensinnigkeit der Sprachpuristen an der Spitze des Go-Schiffs gebe ich kaum etwas dagegen.

Man kann ein Assert-ähnliches Verhalten implementieren, indem man in der Panikfunktion in der letzten Verzögerungsfunktion nach einem speziellen Assert-Fehler sucht und runtime.Breakpoint() aufruft, um den Stapel während der Wiederherstellung zu sichern.Um dieses Verhalten behaupten zu können, muss es an Bedingungen geknüpft sein.Natürlich scheitert dieser Ansatz, wenn nach der Funktion „Assertion“ eine neue Verzögerungsfunktion hinzugefügt wird.Was bei großen Projekten genau zur falschen Zeit passieren wird, was dazu führt, dass Fehler übersehen werden.

Mein Punkt ist, dass „asser“ in vielerlei Hinsicht nützlich ist, dass das Herumtanzen Kopfschmerzen bereiten kann.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top