Vererbung mit mehrfach eingeschränktem TypParamater

[Der schöne Günther]

Ich komme nicht ganz hinterher, was letztendlich dein Ziel ist.

Du hast zwei vollkommen verschiedene Interfaces. Eine Klasse soll jetzt entweder mit IMeinInterface1 ODER IMeinInterface2 parametrisiert werden können. Typeinschränkungen sind immer UND.

Entweder es macht Sinn und du bildest ein gemeinsames Über-Interface (welches fortan die einzige Parametrisierungs-Einschränkung ist)

Delphi-Quellcode:

type
   IMyBaseInterface = interface
      // ?
   end;

   IMyInterface1 = interface(IMyBaseInterface)
      // ?
   end;

   IMyInterface2 = interface(IMyBaseInterface)
      // ?
   end;

   TMeineGenerischeKlasse<T: IMyBaseInterface> = class

   end;

Oder es ist sicher dass es immer bei diesen beiden Interfaces bleiben wird. Dann würde ich die Klasse überhaupt nicht generisch machen sondern halt zwei verschiedene Methoden anbieten- Einmal für

Delphi-Quellcode:

IMyInterface1

und einmal für

Delphi-Quellcode:

IMyInterface2

.


Vielleicht liegt es an mir, aber ich persönlich habe immer große Schwierigkeiten mit vollkommen abstrakten Bezeichnern wie

Delphi-Quellcode:

TKlasse1 = class( TKlasse0<TKlasse> , IKlasse1 ) end;

. Kannst du vlt. ein ganz konkretes Beispiel geben? Kann ja frei erfunden sein, aber irgendwas zum "Anfassen"...

[Dejan Vu]

Zitat:

Zitat von Alexander I (Beitrag 1259479)

Mich stört das ich eine Klasse haben muß, in der beide Interfaces auch noch implementiert werden müßen.

Das geht doch gar nicht anders. Woher willst Du denn wissen, ob Du auf Property-A vom IKlasse1 zugreifen kannst, wenn deine Klasse dieses Interface gar nicht implementiert...

Mir scheint, deine OOP-Überlegungen bedürfen einer gründlicher Überarbeitung.

Zitat:

Zitat von Der schöne Günther (Beitrag 1259486)

Ich komme nicht ganz hinterher, was letztendlich dein Ziel ist.

Zitat:

Zitat von Sir Rufo (Beitrag 1259316)

...aber ich weiß nicht, ob es das ist, was du willst...

Dem schließe ich mich an.

[Alexander I]

Ich hab mal ein pdf erstellt, in dem "ersichtlich" ist wie ich mir das gedacht habe.

Es gibt zwei verschiedene Klassen: Punkte und Vektoren.

Dies erben von einer "abstrakten" BaseTransformationsKlasse die nix kann außer eine Instanz der TranslateKlasse in ihrer eigenen Methode BaseTransformations.Translate zu

instanziieren.

Die TranslateKlasse soll aber von Anfang an wissen welchem Typ sie erwarten soll, damit ich auf die Propertys zugreifen kann, nämlich element.X.

In C# gibts sowas mit where T : .... und da kann man auf Methoden und Propertys sofort zugreifen.


Gruß
Alexander

[Uwe Raabe]

Warum nimmst du nicht einfach IBase als gemeinsamen Vorfahrtyp anstatt der beiden abgeleiteten Interfaces?

Delphi-Quellcode:

BaseTransformation<T: IBase>

Translate<T: IBase>

[Der schöne Günther]

Noch ohne auf die PDF geschaut zu haben: Das

Delphi-Quellcode:

where

in C# ist bei den Typeinschränkungen doch auch nichts anderes als der Doppelpunkt in Delphi. Und statt

Delphi-Quellcode:

new()

heißt es

Delphi-Quellcode:

constructor

.

Code:

public void meineMethode<T>(T meinParameter) where T: ISomeBaseInterface, ISomeOtherInterface

bedeutet in C# doch genauso, dass T beide Interfaces implementieren muss.

PS: Punkte und Vekoren. Ich wusste es :-D

PPS: Warum überhaupt der Unterschied zwischen Punkten und Vektoren? Transformation wie bspw. Translation wird ja sowieso eigentlich doch über einen Vektor in homogenisierter Form mit einer Transformationsmatrix erledigt. Darüber lassen sich alle möglichen Operationen abwickeln.
Aber das führt jetzt nur vom eigentlichen Thema weg... (oder?)

PPPS: Warum möchtest du an der Stelle wissen, ob es nun ein IPoint oder IVector ist? Die richtige Typeinschränkung an diesen Fall wäre übrigens, anders als auf der PDF, IBase und nicht IPoint UND IVector.
Wenn du jetzt zur Laufzeit unbedingt wissen willst ob es nun ein IPoint oder IVector ist kannst du das mit

Delphi-Quellcode:

Supports(..)

überprüfen.

Delphi-Quellcode:

program Project3;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils;

type
   IBaseInterface = interface
      //
   end;

   IChildInterface1 = interface(IBaseInterface)
   ['{65F8AA65-0EED-4D26-A396-26999CD9E316}']
      //
   end;

   IChildInterface2 = interface(IBaseInterface)
   ['{8F390B34-CCF6-4908-B205-D4CD9CF5D3BE}']
      //
   end;

   TIChildClass1 = class(TInterfacedObject, IBaseInterface, IChildInterface1)
      // Es müssen IBaseInterface UND IChildInterface1 angegeben werden.
      // Ja, IBaseInterface ist eigentlich obsolet, aber so ist Delphi halt
      // Stört mich ehrlich gesagt auch
   end;

   TIChildClass2 = class(TInterfacedObject, IBaseInterface, IChildInterface2)
      //
   end;

   TSomeRecord = record
      public class procedure someMethod<T: IBaseInterface>(const someInput: T); static;

   end;

{ TSomeRecord }

class procedure TSomeRecord.someMethod<T>(const someInput: T);
begin
   if Supports(someInput, IChildInterface1) then
      WriteLn('Es ist ein IChildInterface1')
   else if Supports(someInput, IChildInterface2) then
      WriteLn('Es ist ein IChildInterface2')
   ;

end;

begin
  try
   TSomeRecord.someMethod( TIChildClass2.Create() );
  except
    on E: Exception do
     Writeln(E.ClassName, ': ', E.Message);
  end;

  ReadLn;
end.

PPPPS: Generics und im Nachhinein wieder aufdröseln um im Detail nochmal zu schauen was drinsteckt führt Generics ad absurdum. So meine Meinung ohne gründlich drüber nachgedacht zu haben.

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1259526)

PPPPS: Generics und im Nachhinein wieder aufdröseln um im Detail nochmal zu schauen was drinsteckt führt Generics ad absurdum. So meine Meinung ohne gründlich drüber nachgedacht zu haben.

Sehe ich ähnlich. Gleiches gilt wohl sehr häufig auch für Klassen- und Interface-Vererbung. Wenn ich wissen muss, was für ein Abkömmling das ist, mache ich wahrscheinlich was falsch.