Fehlende Mehrfachvererbung bei Schnittstellen

[Der schöne Günther]

Die Frage ist so dumm, ich habe mir ernsthaft überlegt, sie unter anderem Namen zu stellen. Hoffentlich ist es nur die Hitze.

Nehmen wir an, wir haben eine Schnitstelle "Messgerät" und zwei weitere Schnittstellen, die jeweils davon erben. Und wir haben eine Implementation welche diese beiden implementieren wird.

Siehe Bild im Anhang.


Nun habe ich Code der nur Sinn macht wenn ich ein Objekt habe, das diese beiden Schnittstellen implementiert. Da der TFluxkompensator (im Beispiel) nicht die einzige Implementation bleiben wird, möchte ich die Klasse hier nicht ins Spiel bringen- Nur die beiden Interfaces.

Meine Frage: Ich komme also wohl nicht drum herum, mit mindestens zwei verschiedenen Referenzen (Typ IMessgerätKontrollierbar und IMessgerätLivedatenfähig ) zu arbeiten. Das wäre noch vollkommen ok, aber ich bin stark verunsichert, wann ich welche Referenz verwenden sollte, wollte ich eine Methode von IMessgerät verwenden? Klar, die Auswirkungen sind dieselben, aber ich sehe mich jedes mal in Erklärungsnot Warum diese Referenz, warum nicht die andere?

Im Endeffekt fehlt mir eine Typdefinition die sagt: "Implementiert beide Interfaces". Mehrfachvererbung bei Interfaces geht ja in Delphi nicht. In Java hätte ich die Frage nicht stellen brauchen. C++ sowieso nicht In C# weiß ich nicht.

Was habe ich nun für Alternativen?

• Eine Referenz vom Obertyp IMessgerät und runtercasaten wenn man es braucht
• Drei Referenzen und immer die allgemeingültigste nehmen
• Eine andere Möglichkeit. In meiner panischen Internetsuche stieß ich hier öfter auf das "Specification Pattern", verstehe aber auf Anhieb kein Wort.

Das ähnelt auch etwas der Frage
http://www.delphipraxis.net/180380-v...paramater.html
wo versucht wurde, Generics mit "Typ A oder Typ B, beides ok" einzuschränken.


Ergänzung: So würde ich es mit Java machen.

Ich bin für jeglichen Gedankensturm höchst dankbar.

[himitsu]

Zusammenführen (Mehrfachvererbung) ist nunmal grundsätzlich nirgendwo möglich.

Aber es verbietet keiner einem TMessgerät die beiden Interfaces zu implementieren, selbst wenn sie von einem Vorfahren abgeleitet sind.


Vererbung bei Interfaces würde ich persönlich aber eh nur zur Versionierung verwenden.
Die neue Version implementiert die alten Schnittstellen (also erbt sie Diese einfach) und bietet zusätzlich neue/weitere Schnittstellen an.

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