Design von Verträgen und Konstruktoren

Question

Ich implementiere mein eigenes ArrayList für Schulzwecke, aber um die Dinge etwas aufzupeppen, versuche ich C# 4.0 Code Contracts zu verwenden. Alles war in Ordnung, bis ich Contracts zu den Konstruktoren hinzufügen musste. Soll ich Contract.Ensures() im leeren Parameterkonstruktor hinzufügen?

public ArrayList(int capacity) { 
     Contract.Requires(capacity > 0); 
     Contract.Ensures(Size == capacity); 

     _array = new T[capacity]; 
    } 

    public ArrayList() : this(32) { 
     Contract.Ensures(Size == 32); 
    } 

Ich würde sagen ja, jede Methode sollte einen gut definierten Vertrag haben. Auf der anderen Seite, warum, wenn es nur Arbeit an den "Haupt" Konstruktor delegiert? Logischerweise würde ich nicht brauchen.

Der einzige Punkt, den ich sehe, wo es nützlich wäre, den Vertrag in beiden Konstruktoren explizit zu definieren, ist, wenn wir in Zukunft Intelisense Unterstützung für Verträge haben. Wäre dies der Fall, dann wäre es sinnvoll, genau anzugeben, welche Verträge jede Methode hat, wie sie in Intelisense erscheinen würde.

Gibt es auch Bücher, die ein wenig tiefer in die Prinzipien und die Verwendung von Design by Contracts einsteigen? Eine Sache ist das Wissen über die Syntax, wie man Contracts in einer Sprache benutzt (C#, in diesem Fall), andere wissen, wie und wann man sie benutzt. Ich habe mehrere Tutorials und Jon Skeets C# in Depth Artikel darüber gelesen, aber ich würde gerne ein bisschen tiefer gehen, wenn möglich.

Dank

Answer 1

Ich stimme überhaupt nicht mit Thomas Antwort. Solange Sie in der Implementierung von ArrayList() Entscheidungen treffen, sollten Sie einen Vertrag dafür haben, der diese Auswahl dokumentiert.

Hier haben Sie die Wahl den Hauptkonstruktor mit Argument 32 aufzurufen. Es gibt viele andere Dinge, die Sie hätten tun können (nicht nur in Bezug auf die Wahl der Standardgröße). Einen Vertrag an ArrayList() zu geben, der mit dem von ArrayList(int) fast identisch ist, dokumentiert, dass Sie sich entschieden haben, die meisten dummen Dinge nicht zu tun, die Sie hätten tun können, anstatt sie direkt anzurufen.

Die Antwort "es ruft den Hauptkonstruktor auf, so dass der Vertrag des Hauptkonstrukteurs die Aufgabe erledigt" ignoriert völlig die Tatsache, dass der Vertrag da ist, um Sie davor zu bewahren, sich die Implementierung anzusehen. Für eine Überprüfungsstrategie, die auf Laufzeit-Assertion-Prüfung basiert, besteht der Nachteil des Schreibens von Verträgen selbst für solche kurzen Konstruktoren/Methoden, die fast direkt einen anderen Konstruktor/eine andere Methode aufrufen, darin, dass Sie die Dinge zweimal überprüfen. Ja, es scheint redundant zu sein, aber Laufzeit-Assertion-Checking ist nur eine Überprüfungsstrategie und die DbC-Prinzipien sind davon unabhängig. Das Prinzip lautet: Wenn es aufgerufen werden kann, braucht es einen Vertrag, um zu dokumentieren, was es tut.

Answer 2

Umh, ich verstehe nicht ganz, warum Sie die ‚Stellt sicher, dass‘ auch in der c'tor Standard setzen. Weil es den Hauptcontainer nennt, der bereits den vollständigen Vertrag implementiert, tut dies auch der Standardcontainer - per definitionem. Das ist also eine logische Redundanz und daher ein großes "Nicht". Vielleicht könnte es pragmatische Konsequenzen haben, wie Sie sagen - nicht wissen-Code Verträge, die gut ...

In Bezug auf Literatur - die besten Quellen sind:

• Design by Contract, durch Beispiel (Buch, Addison -Wesley)
• Wikipedia article auf die Frage
• An introduction to Design by Contract (Eiffel-Serie, aber DBC Prinzipien sind nicht sprachspezifisch)

HTH! Thomas

Answer 3

Client-Code (mit Code Contracts), die ArrayList verwendet wird nicht wissen, dass die leere Konstruktor Ensure s, dass Size == 32 wenn Sie nicht ausdrücklich so sagen, ein Ensure verwenden.

So (zum Beispiel):

var x = new ArrayList(); 
Contract.Assert(x.Size == 32) 

werden Sie die Warnung "assert nicht bewiesen".

Sie müssen alle Verträge explizit angeben; der Code-Verträge rewriter/static checker „look through“ wird kein Verfahren keine Auswirkungen sehen — my answer to the related question "Do we have to specify Contract.Requires(…) statements redundantly in delegating methods?"

Answer 4

Entwurf durch Vertrag sehen aus den mathematischen Wurzeln der funktionalen Programmierung kommt: Preconditions und Postconditions.

Sie brauchen nicht wirklich ein Buch über sie, es ist höchstens ein Kapitel eines Grads Informatik (die meisten werden das Konzept lehren). Die Grundvoraussetzung ist, dass Sie die Vorbedingungen schreiben, die die Funktion erwartet, und die Ausgabe, die sie mit den richtigen Parametern erzeugt. Es wird nicht erwartet, dass die Funktion mit falschen Anfangsparametern arbeitet. Das Gleiche gilt für einen Algorithmus: Er ist unfehlbar, dh er liefert garantiert das erwartete Ergebnis.

Das ist, wie ich es in dem Grad gelehrt habe ich zur Zeit studiert, kann es allerdings bessere Definitionen sein um. Der Wikipedia-Artikel über Design by contract wird mit einem OO-Schrägstrich geschrieben, aber Pre/Post-Bedingungen sind sprachunabhängig.

Answer 5

Ich empfehle Object Oriented Software Construction, 2nd Edition, oder vielleicht Touch of Class, beide von Bertrand Meyer. Alternativ können Sie den Artikel Applying "Design by Contract" von 1992 vom selben Autor lesen.

Fassen wir zusammen:

• Die Klasseninvariante nach dem Konstruktor halten muss (jeder von ihnen) abgeschlossen ist, und vor und nach jeder öffentlichen Methode der Klasse ausgeführt wird.
• Methodenvoraussetzungen und Nachbedingungen sind zusätzliche Bedingungen, die beim Eingeben und Beenden jeder öffentlichen Methode zusammen mit der Invariante gelten müssen.

Also in Ihrem Fall Fokus in der Invariante. Erzeuge ein korrektes Objekt (eines, das die Klasseninvariante erfüllt), unabhängig davon, welcher Konstruktor aufgerufen wird.

In dieser related answer diskutierte ich ähnliche Themen, darunter ein Beispiel.