3. Design by Contract oder so

Design by Contract oder so

  • B

    Hi,

    ich hab heute diesen Begriff (siehe Titel) gehört, weiß aber nicht worum es sich da handelt, außer dass man so in EIFEL (richtig geschrieben ???) programmiert.

    Welche Vorteile/Nachteile hat es?
    Kann man es auf andere Programmiersprachen (Java, C++, Delphi) übertragen?
    Und wenn ja, dann wie?

    Kennt sich da jemand aus?

    0
  • B

    bIce schrieb:

    ich hab heute diesen Begriff (siehe Titel) gehört, weiß aber nicht worum es sich da handelt, außer dass man so in EIFEL (richtig geschrieben ???) programmiert.

    Das bedeutet, dass du zu jeder Methode Vor- und Nachbedingungen (pre/postconditions) definieren kannst, sowie zu jeder Klasse und Schleife invariante Bedingungen. Sollten diese Bedingungen während der Laufzeit des Programms verletzt sein, wird eine Exception geworfen.

    Eine Vorbedingung kann zB sein, dass das Argument der Wurzelfunktion nicht negativ ist:

    -- mein Eiffel ist leicht rostig, vielleicht ist die syntax nicht 100 prozentig ;)
sqrt(x : double) : double
require x >= 0
is
  -- lalala bissel was berechnen
end

    Eine Nachbedingung, dass das auf dem Stack oben liegt, was gerade gepusht wurde:

    push(arg : sometype)
is
  -- hier wieder irgendwelcher lustiger code
ensure arg = top
end

    Welche Vorteile/Nachteile hat es?
    Kann man es auf andere Programmiersprachen (Java, C++, Delphi) übertragen?

    Direkte Nachteile sind mir nicht bekannt, kann ich mir auch nicht vorstellen, dass es sowas gibt, immerhin kann man die Checks ja (für die Release-Version) abschalten. Vorteile sollten klar sein: Man kann die Schnittstellen seiner Klassen genauer dokumentieren, und die Sprache hilft einem dabei, dass die Schnittstellen auch eingehalten werden.

    Ich kenne keine andere Sprache, in die das direkt eingebaut ist. Bei Java kann man AFAIK mit Aspect-Oriented Programming was basteln, C++ hat mindestens assert, womit man schonmal mindestens ein rudimentäres System für Vorbedingungen aufbauen kann. Leider stecken die natürlich in der Implementierung, nicht in der Deklaration, wie in Eiffel, wo z.B. gefordert wird, dass in abgeleiteten Klassen überschriebene Methoden die Vorbedingung nur lockern und die Nachbedingung nur verschärfen dürfen.

    0
  • B

    Bashar, danke für diese ausführliche Beschreibung.

    EDIT: Der Syntax von EIFFEL errinert mich irgendwie an Pascal, ist es zufällig ein "Nachfolger"?

    0
  • B

    Nein, nur inspiriert (oder ist PHP ein C-Nachfolger? 😉 )

    0
  • R

    Bei Java kann man AFAIK mit Aspect-Oriented Programming was basteln

    Aspekt Orientierte Programmierung kann man ja auch in C++ machen. Hab mich nur noch nicht wirklich damit beschäftigt

    http://www.heise.de/ix/artikel/2001/08/143/

    0
  • H

    Ich kenne keine andere Sprache, in die das direkt eingebaut ist.

    Das hier schon ein par mal angesprochene D, was aber irgendwie keiner mag. Ansonsten fällt mir nur Sather ein. Da es sich um eine Art Eiffel-Nachfolger handelt, ist das aber nicht weiter verwunderlich.

    0
  • B

    Eine "Emulation" gibt es auch für C++, hab hier gefunden http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm

    0
  • S

    @bIce:
    wenn mich das zwingt von einer klasse object abzuleiten ist es blödsinn.

    da gibts schöne ansätze ohne solchen blödsinn - aber so schön wie in eiffel gehts leider nicht.

    0
  • B

    In Eiffel erbt aber alles von ANY 😉

    0
  • S

    Bashar schrieb:

    In Eiffel erbt aber alles von ANY 😉

    eiffel != c++

    in c++ verwendet man kein 'any', deshalb finde ich es blödsinn dies nur wegen dbc einzuführen.

    0
Anmelden zum Antworten