Instanz von T wird mit der abstrakten Methode XYZ angelegt

[Codehunter]

Hallo!

Ich bekomme ein paar Compilerwarnungen der Art

Code:

Instanz von T wird mit der abstrakten Methode XYZ angelegt

Das ist soweit nicht dramatisch, weil die betreffende Klasse diese Methoden tatsächlich nicht benötigt. Mich würde aber interessieren ob es eine elegantere Möglichkeit gibt, diese Compilerwarnung zu beseitigen als leere Dummy-Prozeduren in den implementation-Abschnitt zu schreiben.

Grüße
Cody

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1396577)

Mich würde aber interessieren ob es eine elegantere Möglichkeit gibt, diese Compilerwarnung zu beseitigen als leere Dummy-Prozeduren in den implementation-Abschnitt zu schreiben.

Ja, überarbeite dein Design so, daß die Methode erst in der Ableitungshierarchie deklariert wird, wo sie gebraucht wird. Wenn sie dort immer noch abstrakt sein muss, dann stelle sicher, daß keine Instanz dieser abstrakten Klasse erstellt wird.

[himitsu]

Vor und nach dem Create per Compiler-Befehl die Warnung deaktivieren?

Aber wer sagt dir jetzt, dass in Zukunft diese Methode nicht doch irgendwann mal versucht wird aufzurufen?

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1396582)

Ja, überarbeite dein Design so, daß die Methode erst in der Ableitungshierarchie deklariert wird, wo sie gebraucht wird.

Zitat:

Zitat von himitsu (Beitrag 1396583)

Vor und nach dem Create per Compiler-Befehl die Warnung deaktivieren?

Aber wer sagt dir jetzt, dass in Zukunft diese Methode nicht doch irgendwann mal versucht wird aufzurufen?

Wenn ich das beides jetzt zusammen nehme, dann erscheint es mir am sinnvollsten, die betreffende Methode bereits in der Basisklasse nicht mehr abstrakt zu halten sondern dort mit einer leeren Prozedur anzulegen. So habe ich diesen "Dummy" nur einmal und nicht in jeder abgeleiteten Klasse. Mit dem constructor und destructor von TObject verhält es sich ja ganz ähnlich.

[mkinzler]

Noch besser nicht Basisklasse, sondern erst in der Hierarchie, wenn benötigt

[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

Delphi-Quellcode:

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:

Zitat von Codehunter (Beitrag 1396608)

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

Delphi-Quellcode:

strict protected

.

[Codehunter]

Zitat:

Zitat von Uwe Raabe (Beitrag 1396610)

Es gibt

Delphi-Quellcode:

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?