Verträge für Delphi / Design by Contract

[jaenicke]

Dass der Compiler so etwas erkennt, dürfte in echtem Code allerdings gegen Null gehen. Denn um bei deinem Beispiel zu bleiben eine Funktion absichtlich mit nil aufrufen, wenn die Funktion das gar nicht unterstützt, das mag vielleicht mal passieren, fällt aber beim Test auf und ist leicht zu finden.

Viel wahrscheinlicher und vor allem schwerer zu finden sind aber doch Fehler, die durch zur Laufzeit veränderte Variablen entstehen. Und die kann der Compiler ohnehin nicht erkennen.

[Phoenix]

Zitat von jaenicke:

Viel wahrscheinlicher und vor allem schwerer zu finden sind aber doch Fehler, die durch zur Laufzeit veränderte Variablen entstehen. Und die kann der Compiler ohnehin nicht erkennen.

Doch. Der Code der diese Variablen verändert verwendet ja auch Code Contracts. Und wenn Du dann eine Methode mit einem Contract hat, der nil als rückgabe erlaubt, und den Output in eine reinschieben willst die nil nicht erlaubt (ohne vorher if (blubb <> nil) zu machen), dann kann auch das der Compiler erkennen.

Genau das ist ja gerade die Mächtigkeit von Design by Contract. Wenn man das konsequent durchzieht werden die Contracts direkt gegeneinander validiert und es ist zur Compilezeit möglich sämtliche Fehler durch falsche Ein- und Ausgabeparameter auszufiltern.

[Meflin]

Zitat von Phoenix:

Genau das ist ja gerade die Mächtigkeit von Design by Contract. Wenn man das konsequent durchzieht werden die Contracts direkt gegeneinander validiert und es ist zur Compilezeit möglich sämtliche Fehler durch falsche Ein- und Ausgabeparameter auszufiltern.

Sehe ich völlig anders. Compile-Time Checking von Contracts ist sicherlich ein nice to have, ist aber in der Perfektion äquivalent zur Lösung des Halteproblems (und ist damit unmöglich). Der wichtige Teil an Contracts ist also durchaus der zur Laufzeit Es sei denn deine Aussage bezog sich jetzt wirklich absolut ausschließlich auf falsche Parameter. Dann kann ich nur sagen: Contracts können weit mehr als das.

[Stevie]

Was die Laufzeit Auswertung angeht, kann man das über AOP machen.

[D-User]

für ein Vorbedingungs- Nachbedingungs- Zwischenbedingungs Sonstiges
Kontroll-Konstrukt kann man schön methodenlokale Prozeduren/
funktionen nutzen( die nat. ggf andere Methoden aufrufen).
Je nach Lage der methodenlokalen Variablen zur o.a. Prozedur/Fkt
kann man dann auf diese Variablen und die Parameter wie gewünscht zugreifen
oder aber aus dem Zugriff raushalten.

Mal so auf die Schnelle:

Delphi-Quellcode:

type
  TMyCheckSituation = (sVB, sSit1, sNB );

procedure TForm3.Mach(aInt: integer);
var
  TestMe: integer;

  procedure Chk( const MySituation: TMySituation);
  begin
    case MySituation of
      sVB: if (aInt<8) and ( TestMe<0) then // Testfehler!:
               // irgendwie Fehlerbedingung händeln, z.B: except.
               raise Exception.Create('Loud Cry');
      sSit1: ;// Check für Sit.1
      sNB: ;// Nachbedingungsckeck;
    end;
    DoMyGeneralTest;
  end;

var
  DontTestMe: integer;
begin
  Chk(sVB); // Situationstest Vorbedingung

  DontTestMe := 1;

  MachWas; 
  TestMe := DontTestMe;

  {$REGION 'InnerCheck SaubereMitte'}
  Chk(sSit1); // Situationstest Situation 1
  {$ENDREGION}

  MachNochWas;

  Chk(sNB); // NachBedingung
end;

[Namenloser]

Nur so eine Idee, die mir gerade kam, aber vielleicht könnte man auch records dafür missbrauchen.
Z.B.:

Delphi-Quellcode:

type 
  EContractViolation = class(Exception)
  end;

  TObjectNotNil = record
  private
    FObj: TObject;
  public
    operator Implicit(const Obj: TObject): TObjectNotNil;
    operator Implicit(const Obj: TObjectNotNil): TObject;
  end;

operator TObjectNotNil.Implicit(const Obj: TObject): TObjectNotNil;
begin
  if not Assigned(Obj) then
    raise EContractViolation.Create("Reference must not be nil");
  Result.FObj := Obj;
end;

operator TObjectNotNil.Implicit(const Obj: TObjectNotNil): TObject;
begin
  Result := Obj.FObj;
end;

procedure DoSomethingWithObject(Obj: TObjectNotNil);
begin
  Obj.{...}
end;

DoSomethingWithObject(nil); 
// => EContractViolation

Keine Ahnung, ob Delphi das Konstrukt überhaupt zulässt... ich hatte mit dem Implicit-Operator unter Delphi 2006 schon bei harmloseren Sachen Probleme, aber bei 2006 waren überladene record-Operatoren generell buggy.
Und natürlich ist das so, wie es hier steht, viel zu aufgebläht... aber vielleicht könnte man ja irgendwie einen Preprocessor schreiben, der den Code vor der Kompilierung generiert, oder vielleicht kann man mit Generics noch was rausholen.

Wahrscheinlich ist das alles nicht wirklich praktikabel, aber ich wollte die Idee gerade mal niederschreiben...

[jaenicke]

Zitat von NamenLozer:

Keine Ahnung, ob Delphi das Konstrukt überhaupt zulässt... ich hatte mit dem Implicit-Operator unter Delphi 2006 schon bei harmloseren Sachen Probleme, aber bei 2006 waren überladene record-Operatoren generell buggy.

Ja, das funktioniert so, ohne es gerade testen zu können, abgesehen von den falschen Stringdelimitern und dass das class vor operator fehlt. Auf diese Weise habe ich in ein Dictionary automatisch Lowercase Strings als Key gebracht.

Das funktioniert so aber auch schon mit Delphi 2006 würde ich behaupten, auch wenn ich das gerade nicht testen kann...
Ich habe dort schon relativ viel mit Klassenoperatoren gemacht und hatte damit keine Probleme.