Wie füge ich eine Voraussetzung, die in einer java-Klasse, die Methode oder Konstruktor?

Einige Beispiele, die hier gegeben werden express-Voraussetzungen parameter-Validierung und übt Sie in Behauptungen. Eine nicht-private Methode sollte immer durchführen überprüfung der parameter, wie seine Anrufer aus dem Umfang der Umsetzung.

Neige ich dazu, zu behaupten, dass parameter valdiation nicht als eine Voraussetzung, die im Kontext von Objekt-orientierten Systemen - obwohl ich viele Beispiele für diesen Ansatz in die google-Kugel.

Mein Verständnis von Verträgen gestartet mit [BINDER1999]; die angegebenen Invarianten, Vorbedingung und nachbedingungen in Bezug auf den Zustand des Objekts-unter-test; ausgedrückt als Boolesche Prädikate. Diese Behandlung hält, wie der Staat-Raum gekapselt, die von einer Klasse verwaltet, in dem Methoden repräsentieren übergänge zwischen den Zuständen.

Diskussion der pre - und post-Bedingungen in Bezug auf die parameter und Rückgabewerte ist viel einfacher zu vermitteln, als die Diskussionen in Bezug auf die Zustand-Räume! So kann ich sehen, warum diese Ansicht ist weit verbreitet.

Zur Erinnerung, es gibt drei Arten der Vertrag unter Diskussion:

• Die invariante ist ein test auf die Objekt-under-test welche ist wahr vom Ende der Konstruktion (jeder Konstruktor), zu Beginn seiner Zerstörung (obwohl es gebrochen werden kann, während ein übergang stattfindet).
• Eine Voraussetzung ist ein test auf das Objekt-unter-test muss wahr sein, damit die Methode-unter-test aufgerufen wird, auf das Objekt-unter-test.
• Eine post-Zustand ist ein test auf das Objekt-unter-test, die wahr sein muss, sofort nach der Methode-unter-test abgeschlossen ist.

Wenn Sie treffen die (sinnvolle) Ansatz, dass überladene Methoden sind semantisch äquivalent, dann pre - und post-Bedingungen sind die gleichen für jede überlastung einer bestimmten Methode in eine Klasse.

Wenn interitance und überschriebene Methoden sind als, Vertrags-driven-design Folgen muss, das Liskov-Substitution-Prinzip; die Ergebnisse in der folgenden Regeln:

• Die invariante einer abgeleiteten Klasse ist die logische-UND von seiner lokalen Invarianten, und dass von seiner Basisklasse.
• Die Voraussetzung von einer überschriebenen Methode des logisch-ODER der lokalen pre-Bedingung, und dass die Methode in der Basisklasse.
• Die post-Zustand von einer überschriebenen Methode der logischen-UND der lokalen post-Bedingung, und dass die Methode in der Basisklasse.

Denken Sie daran, natürlich, dass, Wann immer eine pre - oder post-condition geprüft wird, ist die invariante für die class-under-test müssen ebenfalls geprüft werden.

In Java können die Verträge geschrieben werden als geschützt Boolesche Prädikate. Zum Beispiel:

//class invariant predicate
protected bool _invariant_ ()
{
    bool result = super._invariant_ (); //if derived
    bool local  = ... //invariant condition within this implementation
    return result & local;
}

protected bool foo_pre_ ()
{
    bool result = super.foo_pre_ (); //if foo() overridden
    bool local  = ... //pre-condition for foo() within this implementation
    return result || local;
}

protected bool foo_post_ ()
{
    bool result = super.foo_post_ (); //if foo() is overridden
    bool local  = ... //post-condition for foo() with this implementation
    return result && local;
}

public Result foo (Parameters... p)
{
    boolean success = false;
    assert (_invariant_ () && foo_pre_ ()); //pre-condition check under assertion
    try
    {
        Result result = foo_impl_ (p); //optionally wrap a private implementation function
        success = true;
        return result;
    }
    finally
    {
        //post-condition check on success, or pre-condition on exception
        assert (_invariant_ () && (success ? foo_post_ () : foo_pre_ ());
    }
}

private Result foo_impl_ (Parameters... p)
{
    ... //parameter validation as part of normal code
}

Nicht die Rolle der Invarianten Prädikat in der pre - oder post-condition-Prädikate, wie dies hätte zur Folge, invariante wird mehrmals aufgerufen bei jedem test-Punkt in einer abgeleiteten Klasse.

Dieser Ansatz verwendet ein wrapper für die Methode-unter-test, die Durchführung, für die ist jetzt in einer privaten Implementierung Methode, und lässt den Körper der Implementierung unberührt durch den Vertrag Behauptungen. Der wrapper übernimmt auch außergewöhnliches Verhalten - in diesem Fall, wenn die Umsetzung wirft und Ausnahme, der pre-Bedingung erneut geprüft, wie erwartet, für die eine Ausnahme-sichere Umsetzung.

Beachten Sie, dass, wenn, wie im obigen Beispiel, 'foo_impl_()' löst eine Ausnahme aus, und die nachfolgende Voraussetzung, Behauptung in 'finally' block auch fehlschlägt, dann wird die original-Ausnahme von 'foo_impl_()' verloren zugunsten der assertion-Fehler.

Bitte beachten Sie, dass die oben geschrieben ist, aus der top-of-my-head, also Fehler enthalten kann.

Referenz:

• [BINDER1999] Binder "Testing Object-Oriented Systems", Addison-Wesley, 1999.

Update 2014-05-19

Ich gegangen back-to-basics mit Verträgen über ein-und Ausgänge.

Die Diskussion oben, und basierend auf [BINDER1999], als die Verträge in Bezug auf den Zustandsraum der Objekte-unter-test. Modellierung Klassen so stark gekapselt state-Räume ist grundlegend für die Entwicklung von software in einer skalierbaren Weise - aber das ist ein anderes Thema...

Überlegt, wie man die Lyskov substitutionsprinzip (LSP) Eins angewendet wird, kann (und muss) bei der Betrachtung der Vererbung:

Einer überschriebenen Methode in einer abgeleiteten Klasse muss substituierbar für die gleiche Methode in der Basisklasse.

Werden substituierbaren, die Methode in der abgeleiteten Klasse muss nicht mehr restriktiv auf seine input-Parameter als die Methode in der Basis Klasse - ansonsten dann Sie scheitern würden, wo die Basisklasse die Methode gelungen ist, zu brechen LSP Eins.

Ähnlich den output-Wert(s) und den Rückgabetyp (falls dies nicht Teil der Signatur der Methode) muss substituierbar für, hergestellt nach der Methode in der Basis Klasse - es muss mindestens so restriktiv in seiner Ausgabe Werte sonst auch brechen würde LSP Eins. Beachten Sie, dass dies gilt auch für den return-Typ - aus, die Regeln über die co-Variante Rückkehr Typen abgeleitet werden können.

Daher Verträge, die auf der input-und output-Werte von einer überschriebenen Methode folgt den gleichen Regeln für die Kombination des erbschaft-und pre - und post-Bedingungen sind; und um diese Regeln umsetzen effektiv diese umgesetzt werden müssen, getrennt von der Methode, für die Sie gelten:

protected bool foo_input_ (Parameters... p)
{
    bool result = super.foo_input_ (p); //if foo() overridden
    bool local  = ... //input-condition for foo() within this implementation
    return result || local;
}

protected bool foo_output_ (Return r, Parameters... p)
{
    bool result = super.foo_output_ (r, p); //if foo() is overridden
    bool local  = ... //output-condition for foo() with this implementation
    return result && local;
}

Beachten Sie, dass diese nahezu identisch sind, mit foo_pre_() und foo_post_() beziehungsweise, und sollte aufgerufen werden, in der Testumgebung auf dem gleichen test-Punkte, da diese Verträge.

Den pre - und post-Bedingungen definiert, für die eine Methode-die Familie - die gleichen Bedingungen gelten für alle überladenen Varianten der Methode. Die input-und output-Verträge für eine bestimmte Signatur der Methode; jedoch, diese zu verwenden, sicher und vorhersehbar war, müssen wir verstehen, die Signatur-lookup-Regeln für unsere Sprache und für die Umsetzung (vgl. C++ using).

Beachten Sie, dass in der oben genannten, ich benutze den Ausdruck Parameters... p als kurzer hand für einen beliebigen Satz von Parametertypen und-Namen; es ist nicht ment impliziert eine varatic Methode!

InformationsquelleAutor simon.watts

Verwenden Sie einfach assert code die Voraussetzungen. Zum Beispiel:

...
private double n = 0;
private double sum = 0;
...
public double mean(){
  assert n > 0;
  return sum/n;
}
...

InformationsquelleAutor Eamonn O'Brien-Strain

Anwenden Vorbedingungen und nachbedingungen Technik in Java müssen Sie definieren und ausführen von assertions zur Laufzeit. Ist es eigentlich erlaubt, zu definieren, Prüfungen zur Laufzeit im Quellcode.

public boolean isInEditMode() {
 ...
}

/**
* Sets a new text.
* Precondition: isEditMode()
* Precondition: text != null
* Postcondition: getText() == text
* @param name
*/
public void setText(String text) {
 assert isInEditMode() : "Precondition: isInEditMode()";
 assert text != null : "Precondition: text != null";

 this.text = text;

 assert getText() == text : "Postcondition: getText() == text";
}

/**
* Delivers the text.
* Precondition: isEditMode()
* Postcondition: result != null
* @return
*/
public String getText() {

 assert isInEditMode() : "Precondition: isInEditMode()";

 String result = text;

 assert result != null : "Postcondition: result != null";
 return result;
}

Bitte befolgen Sie die details obigen code hier

InformationsquelleAutor tokhi