abstrakte Methoden ignorieren

[himitsu]

tachchen, :hi:

also, ich hab da 'ne gößten Teils abstrakte Basisklasse mit einigen Ableitungen,
allerdings werden da nicht immer alle vordefinierten/abstrakten Prozeduren genutzt/überschrieben
und bleiben demnach abstrakt ... was eigentlich nicht schlimm ist, da diese nicht verwendet werden,
allerdings meckert Delphi leider rum (über 800 Warnungnen sind schon etwas nervend) :cry:

Zitat:

[DCC Warnung] xxx.dpr(25): W1020 Instanz von 'Txxx' mit der abstrakten Methode 'Txxx.xxx' wird angelegt

sooo, und nun die Frage:
kann man diese Meldung, nur bei den entsprechenden Klassen, werglassen,
oder wäre es besser in der Basisklasse diese sinnlose Weise doch nicht als abstrakt zu definieren?

:angel:

[mkinzler]

Ist ja nur eine Warnung. Und duie stimmt ja auch. In anderen Sprachen würde ein Fehler ausgelöst.
Man könnte einfach Stub-Methoden anlegen. Davon würde ich aber Abstand nehmen und mit den Warnungen leben.

[Apollonius]

Ich würde die Methoden in der Basisklasse nur als virtuell markieren und die Implementierung leer lassen (in Prism gibt es dazu die Direktive empty). Abstrakt bedeutet nun mal, dass die Methode überschrieben werden muss.

[himitsu]

ich würd sie ja gern ignorieren, aber

Zitat:

über 800 Warnungnen sind schon etwas nervend) :cry: Crying or Very sad

genauer gesagt sind es aktuell 861 Warnungen und dabei bin ich grad erstma bei den Grundmethoden :drunken:

[add]
@Apollonius: die sind alle als "Virtual; Abstract;", da ich mir die unnötig rumliegenden Prozeduren sparen wollte

[idontwantaname]

Hi!

Das eine Sprache es überhaupt zulässt, dass eine abstrakte Klasse instanziert werden kann, finde ich sehr schockierend, da dieses Verhalten total den Sinn abstrakter Klassen verfehlt.

Bitte überdenke nochmal deine Klassen, du musst einen Fehler im Konzept haben, wenn du auf dieses "Feature" :roll: von Delphi zurückgreifst.

Lg oli

[himitsu]

Die Basisklasse wird auch nie instantiiert, aber in den abgeleiteten Klassen wird nicht immer jede Funktionalität genutzt (drum blieb Einiges dort weiterhin abstrakt)

Aber wie gesagt, alles was Abstract blieb, wird auch nicht (innerhalb dieser Subklasse) genutzt.

Im Notfall muß ich dann wohl doch alle Funktionen nur Virtual machen, da ich diese Warnung nicht global unterdrücken möchte :stupid:

[mkinzler]

Oder das Vererbungsschema verfeinern

[TBx]

Deine Frage könnte man umformulieren in: Kann ich es ignorieren, dass ich selbst verlange, dass Methoden implementiert werden?

Wenn Du mit

Zitat:

virtual;abstract

arbeitest, dann mußt Du die Methoden auch in dem ChildClass überschreiben.

Willst Du in der jeweiligen Kindklasse nur einige Methoden überschreiben, so solltest Du die Methoden nur als virtual anlegen.
Willst Du verhindern, dass diese Klassen in Kindklassen angesprochen werden, obwohl sie nicht entsprechend überschrieben werden, so solltest Du in der Methodenimplementation einfach eine Exception auslösen.

My 2 Cent

Thomas


[Edit]Dreckfuhler[/Edit]

[himitsu]

Wie denn noch verfeinern?

Ich bin froh, daß ich vieles verallgemeinert hab, sond würden da bei noch viel mehr Prozeduren gemeckert :roll: .


@TBx: ich würde es dann natürlich in der Basisklasse ändern, da sonst an mehren Subklassen insgesammt noch mehr Prozeduren sinnlos rumdümpeln :mrgreen:

Und die nötige Exception bzw. das passende Result hät ich schon eingebaut, falls doch mal wer auf die Idee kommt dieses Prozeduren anzusprechen :angel2:



Na OK, wenn es keine Möglihkeit gibt, dann werd ich mal ein paar dutzend Prozeduren nachtragen :?

[mkinzler]

Zitat:

Wie denn noch verfeinern?

Nich alles in Basisklasse

[Uwe Raabe]

Zitat:

Zitat von TBx

Willst Du verhindern, dass diese Klassen in Kindklassen angesprochen werden, obwohl sie nicht entsprechend überschrieben werden, so solltest Du in der Methodenimplementation einfach eine Exception auslösen.

Genau, das wäre das korrekt anzuwendende Muster in deinem Fall.

Man könnte jetzt allerdings einwenden, daß Delphi das ja bereits für dich erledigt und eine EAbstractError Exception auslöst, sollte eine nicht überschriebene abstrakte Methode aufgerufen werden. Inwieweit man das jetzt als schlampiges Design oder geschicktes Ausnutzen dieses Delphi-Features betrachtet, bleibt jedem selbst überlassen.

Und der Vorwurf, daß Delphi einem erlaubt unsinnige Dinge zu tun - also bitte, noch nie ein C++-Programm gesehen?

[himitsu]

@mkinzler: ich versuch ja grad einem Objekten/Interfaces diese knuffigen Operatoren (wie man sie von den Records kennt) beizubringen
und um nicht unmassen an Prozeduren zu benötigen hab ich alles auf ein Interface reduziert.
Also für "Integer" und "Floats" existiert die selbe Basisklasse+Interface, aber z.B. IntegerDivision, Modulo, And und Or werden nicht von Floats unterstützt, wurden also nicht verwendet, aber für die "Integer" sind diese nötig.


Fazit: da es ja nicht möglich zu sein scheint, daß ich diese abstrakt lasse, bau ich grad (in der Basisklasse) die Virtual-Abstrak-Prozeduren in (nur) Virtual um.

[guinnes]

Ich würd die Methoden nur als Virtual kennzeichnen, aber noch dafür sorgen, daß ein AbstractError erzeugt wird, wenn eine Methode benutzt, aber nicht überschrieben worden ist.
Damit hast du sowohl die Meldungen wech, als auch dafür Sorge getragen, daß der Nutzer der Klasse notwendige Methoden überschreibt.

Delphi-Quellcode:

If Self.Classname = TXXX then
  AbstractError;

[himitsu]

blöd, EAbstractError und AbstractErrorHandler sind nicht verfügbar

Delphi-Quellcode:

{$IFNDEF PC_MAPPED_EXCEPTIONS}

[Hansa]

Zitat:

Zitat von himitsu

Also für "Integer" und "Floats" existiert die selbe Basisklasse+Interface, aber z.B. IntegerDivision, Modulo, And und Or werden nicht von Floats unterstützt, wurden also nicht verwendet, aber für die "Integer" sind diese nötig.

Du hast zwar jetzt alles abstract und Meldungen ohne Ende, aber das Problem ist nicht mal richtig abstrahiert. :mrgreen: Modulo & Co. haben bei real nichts zusuchen, bei integer schon. In eine Basisklasse gehört immer NUR das Gemeinsame. MOD ist aber nichts gemeinsames bei integer und reals. Insofern gehört es nicht in eine GEMEINSAME Basisklasse. +-* gehört da rein. DIV / MOD eben nicht. Mache doch TZahl für +-* und leite davon TIntZahl (erweitert um DIV,MOD) ab und dann noch eine TRealZahl mit /. Da könnte man dann noch die Anzahl der Nachlommastellen etc. unterbringen. Bei deinem Ansatz müsste dieser ganze Krempel ja in die Basisklasse. :shock:

[himitsu]

Als Basis für das Basisobject hab ich die möglichen Operatoren
und dann leite ich erst die eigentlichen Typen wie Integer und Float ab.
(das geht Aufgrund des zu Grunde liegenden Interfaces erstmal auch nicht anders)

Nja, das Problem mit den Nachkommastellen muß ich teilweise noch lösen. :oops:

Aber aktuell geht es mir nur darum dem Interface diese Operatoren beizubringen.

Meine aktuellen zwei Test-Objekte sind auch nicht groß ausgebaut ... halt erstmal nur so weit, daß ich testen kann (intern sieht es noch so aus TSmallFloat=Extended und TSmallInteger=Int64)

und TSmallInteger scheint schonmal zu funktionieren :firejump:

[Hansa]

Habs geahnt. 8) Wie gesagt, nicht alle Operatoren gehören in die Basisklasse ! MOD hat da nichts zu suchen. Das ist wie mit einem Werkzeugkasten. Du willst den immer komplett mitschleppen, selbst, wenn nur ein Nagel in die Wand zu schlagen ist. Dazu würde ich zumindest nicht noch Bohrmaschine, Kabeltrommel usw. mitschleppen. :mrgreen:

[himitsu]

ja, aber in der Basisklasse muß doch alles rein, was im Interface drin ist,
sonst meckert Delphi da noch viel böser rum :?

[Mr_G]

Könnte man nicht parallel zu der von Hansa vorgeschlagenen Klassenhierarchie eine passende Interfacehierarchie aufbauen?

[TBx]

Zitat:

Zitat von Mr_G

Könnte man nicht parallel zu der von Hansa vorgeschlagenen Klassenhierarchie eine passende Interfacehierarchie aufbauen?

das wäre wohl das Geschickteste

[himitsu]

Bei den höheren Funktionalitäten wäre das wohl wirklich nicht schlecht (wenn ich die mal irgendwann einbaue), aber das was aktuell drin ist, wurde direkt mit den Operatoren verknüpft und da ist nichts mit Klassen- und Interface-Hierarchien.

[himitsu]

Zitat:

Zitat von himitsu #14

blöd, EAbstractError und AbstractErrorHandler sind nicht verfügbar

Delphi-Quellcode:

{$IFNDEF PC_MAPPED_EXCEPTIONS}

OK, blöd wenn man nicht richtig guckt und nur mit Einem von Beiden testet. :oops:
AbstractErrorHandler ist doch garnicht sichtbar/freigegeben ... ich ruf den jetzt einfach über die Variable {System.}AbstractErrorProc auf :stupid: