Ist Vererbung streng linear?

[taaktaak]

Sorry, wenn der Titel fachlich unkorrekt formuliert ist, aber da mir das Thema fremd ist, ist mir nichts besseres eingefallen.

Also, bevor ich mich möglicherweise in eine falsche Richtng bewege, möchte ich eine konzeptionelle Frage geklärt wissen. Ich versuche die Fragestellung am besten mit einem Beispiel zu erläutern:

Ich habe eine Basisklasse mit der Funktionsmenge A und füge durch Ableitung und Erweiterung eine Funktionsmenge B hinzu; meine neue Klasse besitzt dann die Funktionsmenge AB. Für eine andere Aufgabe verwende ich wiederum die Basisklasse A und füge eine Funktionsmenge C hinzu, meine neue Klasse beinhaltet damit die Funktionsmenge AC. Im Laufe der Zeit entstehen auf diese Art und Weise mehrere neue Klassen jeweils mit dem Vorfahren A und den neuen Funktionsmengen AB, AC, AD, AE etc.

In einem neuen Anforderungsprofil seien zu einem späteren Zeitpunk die Funktionsmengen A, C und D notwendig - habe ich dann die Möglichkeit die Klassen AC und AD gemeinsam als Vorfahren einer neuen Klasse mit der Funktionsmenge ACD zu vereinen?

[mkinzler]

In Delphi nicht, da Delphi keine Mehrfachvererbung unterstützt.

[taaktaak]

Danke für die schnelle Antwort! Also ist meine Idee/Überlegung in anderen Sprachen umgesetzt worden. Welche Sprachen ermöglichen ein solches Vorgehen?

[DeddyH]

In C++ geht das z.B. AFAIK (ih kann mich aber auch irren, meine das aber gelesen zu haben).

[mkinzler]

c++. Da aber Mehrfachvererbung zu Problemen führt unterstützen neuere Sprachen wie Delphi, Java, c#, ... keine Mehrfachvererbung von Klassen mehr. es wird nur die Mehrfachvererbung von Interfacen unterstützt.

[Neutral General]

Wie mkinzler schon gesagt hat: Sowas funktioniert in Delphi nicht.

Was du allerdings machen kannst ist ein eine Klasse auf Basis mehrerer Interfaces.

Also z.B.

Delphi-Quellcode:

type
  IOne = interface(IUnknown) 
    ['..']
    procedure One;
  end;

  ITwo = interface(IUnknown)
    ['..']
    procedure Two;
  end;

  TOneTwo = class(TInterfacedObject, IOne, ITwo)
  public
    procedure One;
    procedure Two;
  end;

Ist natürlich jetzt nicht so das was du wolltest aber naja. Sowas ähnliches halt :mrgreen:

Gruß
Neutral General

[taaktaak]

Ok, deswegen werde ich nicht auch noch C++ lernen wollen. Das würde meinen Hobby-Zeitrahmen dann endgültig sprengen. In der Konsequenz muss man also in Delphi immer "linear oben drauf packen".

Führt spontan zu folgender An- und Abschlußfrage: Wird Code aus eingebundenen Units nicht vom Programm genutzt, dann wird ja wohl der Code auch nicht in die EXE eingebunden! Ist das bei den verwendeten Klassen auch so? Also, um beim Beispiel zu bleiben ich habe eine "Superklasse" mit der Funktionsmenge ABCDE, verwende aber nur ACD - wird dann der Code von B und E auch "außen vor gelassen"?

Kannn ich mir eigentlich nicht so recht vorstellen...

[taaktaak]

Huhhh, Neutral General, sei nicht enttäuscht, aber das sagt mir erst einmal gar nix. Da ich jetzt aber doch schon recht müde bin, möchte ich da auch nicht weiter einsteigen. Ich schaue mir das morgen mal an - Danke an alle für die Antworten :hi:

[HERMES]

Oder eine Fasade(siehe Entwurfsmuster) einführen. Das ist eine Klasse, die in deinem Beispiel die Funktionsmenge ACD hat. Dazu muss jeder Funktionsaufruf an ein Objekt der entsprechenden Klasse weitergeleitet werden. Allerdings musst du aufpassen, dass dein Kontext immer aktuell ist, für den Fall dass die Berechnung einer Funktion von irgendwelchen Objektvariablen abhängt.

[mkinzler]

Das Problem an der Mehrfachvererbung ist es, dass sie u.U. zu Inkonsistenzen führen kann, wenn mehrere Basisklassen verschiedene Implementierungen einer Methode haben.
Bei Interfaces handelt es sich von attributlose vollständig abstrakte Klassen. So kann es zu zu keine Konflikte kommen.

[Apollonius]

Aber das Wahre sind Interfaces auch nicht, da eben nicht die Implementierung vererbt wird, sondern nur die Schnittstelle. Das heißt, dass man die Funktionalität immer neu schreiben muss, höchstens mit "implements" kann man sie vererben, was aber schnell zum Krampf wird.

[sirius]

Zitat:

Zitat von taaktaak

Führt spontan zu folgender An- und Abschlußfrage: Wird Code aus eingebundenen Units nicht vom Programm genutzt, dann wird ja wohl der Code auch nicht in die EXE eingebunden! Ist das bei den verwendeten Klassen auch so? Also, um beim Beispiel zu bleiben ich habe eine "Superklasse" mit der Funktionsmenge ABCDE, verwende aber nur ACD - wird dann der Code von B und E auch "außen vor gelassen"?

Das dürfte nur für private statische Methode gelten. Aber du kannst es ja testen.

[grenzgaenger]

Zitat:

Zitat von taaktaak

Führt spontan zu folgender An- und Abschlußfrage: Wird Code aus eingebundenen Units nicht vom Programm genutzt, dann wird ja wohl der Code auch nicht in die EXE eingebunden! Ist das bei den verwendeten Klassen auch so? Also, um beim Beispiel zu bleiben ich habe eine "Superklasse" mit der Funktionsmenge ABCDE, verwende aber nur ACD - wird dann der Code von B und E auch "außen vor gelassen"?

wie bereits gesagt, ist C++ eine der wenigen sprachen die mehrfachvererbung unterstützt, in delphi wurde sie bewusst aussen vor gelassen. alle referenzen, die nicht verwendet werden, werden auch vom linker nicht in die exe eingebunden. wenn du allerdings intern verschiedene methoden verwendest, diese als verwendet erkannt und nicht entfernt. (wie kann es anders sein). 'ne integrierte kristallkugel mit 'ner 100%igen zuverlässigkeit hat auch codegear nicht.

als notnagel wurden irgendwelche interfaces eingeführt, von dennen kein mensch weiss was das eigenlich ist, zumindest ich nicht ;-)

du wirst also nicht dran vorbeikommen, 'n sauberes klassenkonzept aufzusetzen...

<HTH>

[xaromz]

Hallo,

Zitat:

Zitat von grenzgaenger

als notnagel wurden irgendwelche interfaces eingeführt, von dennen kein mensch weiss was das eigenlich ist, zumindest ich nicht ;-)

Vorsicht! Interfaces sind ein richtig nützliches Feature. Man muss nur wissen, wann und wie man das einsetzt. Nicht umsonst bietet nahezu jede moderne Objektsprache Interfaces (ich bin z. B. neulich über Interfaces in ActionScript 3 gestolpert, da reden wir quasi von Javascript). Dass Interfaces eine Krücke für Mehrfachvererbung sind (da gebe ich Dir Recht) ist eher ein Nebenprodukt des eigentlichen Zwecks.

Gruß
xaromz

[r2c2]

Zu erwähnen wär vllt. noch, dass die Interfaces in Delphi AFAIK hauptsächlich für die ganzen COM-Geschichten genutzt werden. Deshalb sind sie, wenn man sie wie "normale" Interfaces verwenden will, IMHO etwas unhandlich(Wenn man Pech hat, darf man noch an der Referenzzählung rumspielen, etc.). So richtig genutzt wie in .NET werden Interfaces in Delphi deshalb nicht. Dafür gibts ne ganze Menge abstrakter Klassen. Eigentlich Schade. Wenn man mal n bisschen .NET programmiert hat, merkt man erst wie praktisch Interfaces eigentlich sind...

Es gibt aber auch noch einen 3. Weg. Zusätzlich zur problematischen Mehrfachvererbung und den manchmal unhandlichen, weil zu redundantem Code führenden, Interfaces: Mixins. Das sind Interfaces mit Implementierung(wohlgemerkt: keine vollständigen Klassen!). Bringen zwar wieder das ein oder andere Problem der Mehrfachevererbung, sind aber sehr flexibel und neigen nicht so zu redundantem Code. Wer Mixins in Aktion sehen möchte, kann sich ja mal Ruby angucken...

mfg

Christian

[Meflin]

Zitat:

Zitat von grenzgaenger

als notnagel wurden irgendwelche interfaces eingeführt, von dennen kein mensch weiss was das eigenlich ist, zumindest ich nicht ;-)

Nunja, Interfaces sind genial, denn dank ihnen kannst du Dinge (Klassen) in dein Programm einbauen, die es noch garnicht gab als du dein Programm programmiert hast :mrgreen: Das öffnet definitiv einen Haufen ungeahnte Möglichkeiten, ich beschäftige mich seit kurzem mit Interfaces und ich möchte sie nicht mehr missen.

Hauptsächlich wurden die Interfaces aber doch für die COM und ActiveX-Kompatibilität eingeführt, wenn ich mich nicht irre :gruebel:
Edit: wie ja auch mein Vorschreiber schon erwähnt hat :)

Also mit anderen Worten: Interfaces sind nicht wirklich als Ersatz für MEhrfachvererbung gedacht!

[r2c2]

Um nochmal auf das eigentliche Problem zurück zu kommen:
Eine Möglichkeit wäre die Komposition. Das ist das, was hinter dem ober erwähnten Entwurfsmuster Fassade steckt. Du machst einfach folgendes:
- Klasse A
- Klassen B, C und D
- von A abgeleitete Klassen AB, AC, AD, ACD, ...
- dazu werden in diesen Klassen private Objekte B, C und D benötigt bzw. benutzt
==> Komposition.

Unterschied zur reinen Fassade: Du leitest von A ab und sparst dadurch Arbeit...

mfg

Christian