abstrakte Methoden ignorieren

[Uwe Raabe]

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
{$IFNDEF PC_MAPPED_EXCEPTIONS}

[Hansa]

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. 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.

[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.

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

[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.

[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 von Mr_G:

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

das wäre wohl das Geschickteste