Fehlende Mehrfachvererbung bei Schnittstellen

[Der schöne Günther]

Richtig. Es realisiert beide. Das ist ja auch nicht das Problem.

Der TFluxkompensator (oder andere Klassen) selbst sind nicht das Problem. Es geht um den Code der sich mit Messgeräten befassen soll, die sowohl Livedaten bereitstellen als sich auch steuern lassen. Wie ich den am besten aufziehe: Habe ich hier (für ein Objekt) zwei verschiedene Variablen oder gibt es bessere Wege in Delphi?

[himitsu]

Interfaces lassen sich inzwischen (fast) wie Objekte casten.
- harte Casts sind zwar verboten, da unterschiedliche Interfaces auch unterschiedliche Referenzzeiger (Pointer-Adressen) besitzen,
im gegensatz zu Klassen-Typcasts, welche alle die selbe Referenz (Adresse) besitzen.
- aber soft-casts (AS) sind erlaubt

[Der schöne Günther]

Also du würdest mit einer IMessgerät-Referenz arbeiten und jedes mal (da es klar ist dass die Instanz beide Unter-Interfaces implementiert) runtercasten?

Delphi-Quellcode:

type TMessgeräteBehandler = class
   protected var
      myMessgerät: IMessgerät;
   public
      constructor Create(myMessgerät: IMessgerät);
      procedure behandleGerät();
   
end;

procedure TMessgeräteBehandler.behandleGerät();
begin
   if not myMessgerät.störungsfrei() then [...]
   
   WriteLn(
      'Aktuelle Temperatur: '
      + (myMessgerät as IMessgerätLivedatenfähig).getTemperatur().toString()
   );
end;

[himitsu]

Also grundsätzlich arbeite ich dann immer mit dem Typen, welcher am Meisten benötigt wird und der Rest wird gecastet.
Wenn kurz hintereinander mehrfach auf das andere Interface zugegriffen wird, dann wird in einer Temp-Variable kurz zwischengespeichert. (oder im extremen Notfall auch mal ein WITH)

Aber du kannst den Cast auch intern machen.
s := myMessgerät.Livedaten.getTemperatur.toString;
Livedaten castet intern und gibt als Result ein IMessgerätLivedatenfähig zurück.
iMessgerät erbt dann vom Wichtigeren und referenziert das Andere.

[Der schöne Günther]

Als Ergänzung vielleicht noch: So würde ich es in Java machen:

Code:

class App
{
   public static void main (String[] args) throws java.lang.Exception
   {
      IBoth myVar = new BothImplementer();
      myVar.subMethod1();
      myVar.subMethod2();
   }
}

interface IBase {
   // Stub
}

interface ISub1 extends IBase {
   void subMethod1();
}

interface ISub2 extends IBase {
   void subMethod2();
}

// Reines Tagging-Interface
interface IBoth extends ISub1, ISub2 {}

// Muss das Tagging-Interface implementieren
class BothImplementer implements ISub1, ISub2, IBoth {
   public void subMethod1() {
      System.out.println("submethod1");
   }
   public void subMethod2() {
      System.out.println("submethod2");
   }
}

In Delphi ist die Deklaration von IBoth nicht möglich.

[himitsu]

Schlimm ist ja, daß selbst ein Singlepasscompiler, wie Delphi, theoretisch Mehrfachvererbung anbieten könnte,
also rein von den "sichtbaren" Schnittstellen, welche der Programmierer sieht. (vor dem Compilieren)

Man würde einfach nur beim neuen "kombinierten" Objekt/Interface die direkten Schnittstellen der Vorfahren nochmals durch den Compiler jagen und dabei die bekannten Fehlermeldungen werfen, wenn sich etwas überschneidet.

Zitat:

[dcc32 Fehler] Unit23.pas(39): E2254 Die überladene Prozedur 'Read' muss mit der Direktive 'overload' gekennzeichnet sein

[dcc32 Fehler] Unit23.pas(39): E2252 Es gibt bereits eine Methode 'Read' mit identischen Parametern

Nur bei der RTTI müsste man sich was überlegen, wie man das macht.
Und auch die IS/AS-Prüfungen, und Ähnliches, würden etwas aufwändiger, da man dann ja keine lineare Vererbung mehr hat, sondern einen Baum.


Aber nein, es ist dennoch nicht möglich, in Delphi eine Mehrfachvererbung hinzubekommen.
(jedenfalls nicht so, daß man die Typen, so wie es jetzt möglich ist, einfach so blind in die neuen Vererbungslinien casten kann)
In dynamischen Sprachen, welche paktisch alles zur Laufzeit parsen und nicht mit festen Indize/Adressen arbeiten, wie z.B. Java/PHP/JavaScript, ist das halt was Anderes.

Klasse/Interface 1
* Addresse 1 = Funktion A
* Addresse 2 = Funktion B

Klasse/Interface 2
* Addresse 1 = Funktion C
* Addresse 2 = Funktion D

Klasse/Interface 1+2
* Addresse 1 = Funktion A oder Funktion C
* Addresse 2 = Funktion B oder Funktion D

(das Selbe nochmal für alle Felder/Variablen in der Klasse usw.)


Wenn man jetzt auf Adresse 1 zugreift, bei wem soll man denn nun rauskommen?

[himitsu]

Auch für Delphi ist das "möglich", aber man muß da etwas aufpassen und in den zweiten, dritten und x-ten Vererbungslinien, neben der Hauptvererbungslinie, sind bestimmte Dinge nicht mehr möglich.

In dem neuen kombinierten Typen ist dann (intern) nur die erste Vererbungslinie wirklich vererbt und alle anderen Felder/Funktion sind praktisch in den neuen Typen reinkopiert. (so wie bei den Generics)

[BUG]

Du könntest die Hierarchie auch auf den Kopf stellen:
Dein Messgerät hat allgemeine Schnittstelle (IMessgerät), welche zusätzliche Sichten auf Messgerät (also die anderen Interfaces) erzeugen kann. Vererbung gibt es unter den Interfaces keine. Die Klassen, welche IMessgerätLivedatenfähig (und so weiter) bereitstellen, müssen dabei noch nicht einmal mit TFluxKompensator verwandt sein, sondern werden vielleicht nur von der TFluxKompensator-Instanz zur Laufzeit erstellt und konfiguriert.

Zitat von himitsu:

Aber nein, es ist dennoch nicht möglich, in Delphi eine Mehrfachvererbung hinzubekommen.
In dynamischen Sprachen, welche paktisch alles zur Laufzeit parsen und nicht mit festen Indize/Adressen arbeiten, wie z.B. Java/PHP/JavaScript, ist das halt was Anderes.

Du weißt schon, das C++ Mehrfachvererbung anbietet, sicher keine dynamische Sprache ist und man dort trotzdem den meisten Probleme bei der Mehrfachvererbung relativ intuitiv umgehen kann

Eigentlich sollte es mit "Mehrfachvererbung" von Interfaces überhaupt kein Problem geben, eben weil nur eine Schnittstellenbeschreibung ohne Implementierung ist.