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 von Codehunter:

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 von Uwe Raabe:

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

Zitat von 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?

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 EAbstractError -Exception werfen. Dann bekommst du wenigstens mit, wenn sich am Aufrufverhalten ungewollt etwas ändert.