Klassen mit unterschiedlichen Parents verwursten

[transporter08]

Hallo zusammen,

ich habe folgende Struktur bei einer Klassendefinition:

Basisklasse : TFooBase
davon abgeleitet: TFooClass1 = class(TFooBase), TFooClass2 = class(TFooBase)

jetzt möchte ich wiederum ein Set von gemeinsamen Eigenschaften und Funktionen
definieren, die in jede der abgeleiteten Klassen (TFooClass1/2) drinne sein soll.
In TFooBase haben sie in diesem Level (noch) nichts zu suchen, weil TFooBase
als Basis weiterer (anderwertiger) Ableitungen dienen soll.
Also so soll es in etwa aussehen:

???
Funktion1 virtual;
Funktion2 virtual;
???

TFooClass1
Funktion1 override;
Funktion2 override;

TFooClass2
Funktion2 override;

Ist das in der Form irgendwie machbar ?

Danke schonmal.

[DeddyH]

Hallo und Willkommen in der DP :dp:,

ja, das geht. Wenn ich Dich richtig verstanden habe, dann suchst Du das Schlüsselwort abstract.

Delphi-Quellcode:

type
  TBaseClass = class
  protected
    function Func1; virtual; abstract; //wird hier noch nicht implementiert
    function Func2; virtual; abstract; //s.o.
  end;

  TChild1 = class(TBaseClass)
  protected
    function Func1; override; //Implementation erfolgt erst hier
    function Func2; override;
  end;

[transporter08]

Nein, das ist leider nicht das was ich suche.

ich versuch's nochmal etwas zu verdeutlichen:

Eigentlich müssten (nur zum Verständnis)

Funktion1 virtual;
Funktion2 virtual;

in TFooBase aufgenommen werden, damit sich TFooClass1 und TFooClass2 beide auf den gleichen
Funktionsrumpf beziehen können.

Aber da TFooBase eine allgemeine Basisklasse darstellt, kann ich sie hier nicht aufnehmen,
sondern erst ab TFooClass1 bzw. TFooClass2. Kann ich ab diesem Level noch gemeinsame Dinge aufnehmen,
die von den abgeleiteten als Basis angesehen werden.

[DeddyH]

Nur dass ich das richtig verstehe: die Basisklasse hat thematisch nichts mit den beiden Funktionen zu tun, die kommen erst in der ersten Ableitung ins Spiel (also TFooClass1 bzw. TFooClass2), stimmt das soweit?

[transporter08]

Ja das ist korrekt.

[DeddyH]

In dem Fall würde ich einfach noch eine Klasse "dazwischenschieben", TFoo1 und TFoo2 erben dann von der und nicht mehr direkt von der Basisklasse.

[Lemmy]

Hi,

und wenn das nicht möglich ist (Klasse dazwischen) das Klassenmodell noch einmal überarbeiten oder alternativ mit Interfaces arbeiten (etwas komplexer wie reine OOP)

Grüße

[transporter08]

Die Sache ist die, dass in TFooClass1 und TFooClass2 jeweils unterschiedliche Objekte definiert sind und angesprochen werden (müssen).
Allerdings habe ich im weiteren Verlauf einen zentralen "Ansprechpartner" (TFooContainer), der dann entweder mit TFooClass1 oder TFooClass2 arbeiten soll. Damit nicht jedesmal fuer einen Funktionsaufruf unterschieden werden muss, ob die Klasse jetzt TFooClass1 oder TFooClass2 ist (weil sie ja eigentlich einen gemeinsamen Funktionsschatz haben), war die Überlegung mit den zusätzlichen Gemeinsamkeiten.

Würden die Interfaces so etwas abdecken ?

[DeddyH]

Sowohl Interfaces als auch die "Zwischenklasse" würden das abdecken.

[himitsu]

Zitat:

Klassen mit unterschiedlichen Parents verwursten

Das hatte ich erst falsch verstanden.
Stichwort: Mehrfachvererbung
Und sowas ginge nicht.

[edit]
Oder hab ich's richtig verstanden. :grubel:

[transporter08]

Die Zwischenklasse ist leider auch nicht möglich, weil TFooClass1 und TFooClass2 wiederum Basisklassen bilden, von denen an anderer Stelle Ableitungen stattfinden (nennen wir sie TFooClass1ZweigA und TFooClass2ZweigA (diese Ableitungen haben aber ihrerseits nichts mit Funktion1/Funktion2 zu tun). Die Funktion1/Funktion2 soll nur (gemeinsam nutzbar) in TFooClass1ZweigB bzw. TFooClass2ZweigB wenn möglich.

[Lemmy]

Dann bleibt nur noch das Interface. Oder eben die Überlegung ob dein Klassenmodell in sich noch passt.

Ah ne... eine GEschichte noch: Ich kenne die Hintergründe nicht, aber du könntest ggf. das gemeinsame Verhalten in einer weiteren Klasse abbilden, die dann von den entsprechenden Klassen einfach genutzt wird (nennt sich Komposition).

Grüße

[DeddyH]

Ich bekomme das Gefühl, Du solltest Dein Klassenmodell vielleicht noch einmal überdenken (oder ich verstehe Dich völlig falsch, das kann natürlich auch sein) :gruebel:

[Robotiker]

Ich würde auch mal vermuten, dass man das in Delphi über Interfaces lösen sollte.

Der Fragesteller will wahrscheinlich etwas, was man in C++ ungefähr so lösen würde:

Code:

template<typename T>
class Foo : public T
{
  // Irgendeine Implementierung
};

Also (ggf. Mehrfach-) Vererbung von einen Generic. Geht das in Delphi ?

[himitsu]

Nur geht sowas in den Delphi-Generics leider nicht. :cry:

[Robotiker]

Zitat:

Zitat von himitsu (Beitrag 1155008)

Nur geht sowas in den Delphi-Generics leider nicht. :cry:

Ok, danke. Dann sollte man das OO-Design besser den Möglichkeiten der Sprache anpassen.

[transporter08]

Also ich mache nochmal ein (nur zur Verdeutlichung) Beispiel aus dem Fahrzeugbereich:

TFooBase stellt die Basis dar mit Eigenschaften wie z.B. 4 Räder.

TFooClassBenzin => class(TFooBase) mit zusätzlichem Objekt Benzinmotor
TFooClassElektro => class(TFooBase) mit zusätzlichem Objekt Elektromotor

TFooClassKFZBenzin => class(TFooClassBenzin ) Basisklasse für z.B. KFZ mit Benzinmotor
TFooClassKFZElektro => class(TFooClassElektro) Basisklasse für z.B. KFZ mit Elektromotor

TFooClassLKW => class(TFooClassBenzin ) Basisklasse für z.B. LKW mit Benzinmotor :-)

TFooClassKFZBenzin + TFooClassKFZElektro sollen jetzt noch die zusätzlichen gemeinsam nutzbaren Funktionen
Funktion1/Funktion2 für z.B. ausschliesslich den KFZ-Bereich. Eine Zwischenklasse KFZ zwischen TFooBase und TFooClassBenzin/TFooClassElektro geht hier nicht, weil die KFZ-Funktionen direkt schon den Benzin bzw. Elektromotor ansprechen müssen.

Natürlich würde ich einen Fahrzeugbereich etwas anders abbilden, aber so wäre mein momentanes Problem strukturiert. Hoffe, es ist nun etwas klarer.

[stahli]

Ich denke, das wäre in Delphi ein klassischer Fall für den Einsatz von Interfaces. So musst Du im späteren Einsatz nicht ständig die Objekte casten.

Man erreicht auch eine losere Bindung der einzelnen Klassen.

Allerdings ist ein gewisser Mehraufwand durch die Deklaration der Schnittstellen notwendig und die Speicherverwaltung ist im Projekt anders als mit reinen Objekten zu organisieren.

[transporter08]

Danke für die Auskünfte.