Instanz von T wird mit der abstrakten Methode XYZ angelegt

[Codehunter]

Das ist richtig, im konkreten Fall jedoch etwas unpraktikabel, weil es ein Delphi Starter ist. Ich müsste weiter oben in der Hierarchie schon abzweigen und dann jede Menge nachimplementieren. Da ist es deutlich einfacher und sicherer, einfach leere Prozeduren anzulegen. Im ungünstigsten Fall passiert dann einfach gar nichts, aber es kracht nicht mit einer Abstract Exception. Da es sich bei den bisher abstraktion Methoden um Functions handelt, gebe ich einfach den Defaultwert zurück, auf den ich dann in der Routine prüfen kann, wo dynamisch die eine oder andere Kindklasse verwendet wird.

[Uwe Raabe]

Wenn du sicher bist, daß die Methoden nur in überschreibenden Klassen verwendet werden, kannst du auch in der Dummy-Methode eine Assertion einbauen oder eine EAbstractError -Exception werfen. Dann bekommst du wenigstens mit, wenn sich am Aufrufverhalten ungewollt etwas ändert.

[Codehunter]

Da hast du völlig recht Uwe. Die Idee finde ich sogar sehr gut, in der Basisklasse eine Art von Not-Implemented-Benachrichtigung einzubauen. Irgendwie finde ich es schade, dass es neben den protected- und public-Abschnitten in Klassen nicht auch einen gibt wo man Methoden deklarieren kann, die ausschließlich in Kindklassen angesprochen/überschrieben werden können und deren Sichtbarkeit nach außen hin in Kindklassen nicht erhöht werden kann. Also ungefähr sowas:

Delphi-Quellcode:

type
  TMyBaseClass = class(TObject)
  private

  protected

  descendend
    procedure MyMethod; virtual; obligatory;
  public

  end;

  TMyChildClass = class(TMyBaseClass)
  descended
    procedure MyMethod; override;  // <-- Klappt
  end;

  TMyChildClass2 = class(TMyBaseClass)
  public
    procedure MyMethod; override; // <-- Compilerfehler wegen erhöhter Sichtbarkeit
  end;

  TMyChildClass3 = class(TMyBaseClass)
  descendend
    // MyMethod wird nicht implementiert, Compilerfehler
  end;

Damit könnte man von vornherein ausschließen, dass solche Methoden nach außen hin sichtbar werden. Ein Konstrukt aus protected Methode + final trifft das irgendwie nicht so richtig. Das Statement "obligatory" würde die Implementierung einer Methode in Kindklassen erzwingen - "abstract" lässt es ja offen und im Zweifel kracht es.

[Uwe Raabe]

Zitat von Codehunter:

Irgendwie finde ich es schade, dass es neben den protected- und public-Abschnitten in Klassen nicht auch einen gibt wo man Methoden deklarieren kann, die ausschließlich in Kindklassen angesprochen/überschrieben werden können.

Es gibt strict protected .

[Codehunter]

Zitat von Uwe Raabe:

Es gibt strict protected .

Tatsache Da wird man alt wie eine Kuh und lernt immer noch dazu... Gibts vielleicht auch sowas wie das "obligatory" in meinem Beispiel?

[Uwe Raabe]

Zitat von Codehunter:

Gibts vielleicht auch sowas wie das "obligatory" in meinem Beispiel?

Nicht direkt in der Form, aber du kannst in den Projekt-Optionen unter Hinweise und Warnungen bei der Warnung Konstruierende Instanz enthält abstrakte Methode den Eintrag auf Fehler stellen, dann compiliert der Source so nicht mehr.

[Codehunter]

Hmmm womit wir wieder beim abstract wären Aber ich meine mich zu erinnern, dass das früher bei D7 von Haus aus so war, dass der Compiler abgebrochen hat wenn Abstracts nicht implementiert waren. Mit dem strict protected bin ich aber schon mal ein gutes Stück weiter beim ordentlichen Anwendungsdesign.