Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Object-Pascal / Delphi-Language (https://www.delphipraxis.net/32-object-pascal-delphi-language/)
-   -   Generisches Alias von TFrame (https://www.delphipraxis.net/196339-generisches-alias-von-tframe.html)

hzzm 14. Mai 2018 10:50

Delphi-Version: 10 Seattle

Generisches Alias von TFrame
 
Tut mir leid, dass ich Euch schon wieder belaestigen muss.
Ich haenge an etwas so simplem, aber die Loesung ist nicht greifbar:

Ich versuche ganz einfach ein generisches Alias fuer einen Frame zu deklarieren.
Nach einiger googlerei denke ich, dass ich einfach die "CreateNew" statt "Create" wie bei TForm fuer TFrame suche.
Aber mal ganz von vorne:
Delphi-Quellcode:
type
  TSpeziellerFrame = class(TFrame)
    [...]
  End;

  TKanne<TObjectList> = class( TSpeziellerFrame; ) // ohne class() kompilierts gar nicht
Delphi-Quellcode:
constructor TJodokus<T>.Create(AOwner: TComponent);
var
  AView: TKanne<T>;
begin
  AView := TKanne<T>.Create(AOwner); // hier krachts: TCustomFrame.Create-> not InitInheritedComponent(Self, TFrame) -> raise EResNotFound
end;
Delphi-Quellcode:
begin
  TJodokus<TObjectList>.Create(Self);
end;
Gibt es irgendeinen legitimen Grund, warum das nicht von Natur aus funktioniert?!
Habe schon etliche Konstellationen probiert, komme aber einfach nicht drauf.
Danke fuers Lesen!

Rollo62 14. Mai 2018 11:14

AW: Generisches Alias von TFrame
 
Warum das nicht läuft habe ich jetzt nicht gecheckt, aber
wäre nicht ein Interface das was du suchst statt die Klasse selbst zu speichern ?

Delphi-Quellcode:
type
  TSpeziellerFrame = class(TFrame, ISpeziellerFrame)
    [...]
  End;
Rollo

himitsu 14. Mai 2018 11:46

AW: Generisches Alias von TFrame
 
Zitat:

ohne class() kompilierts gar nicht
Natürlich nicht, denn du willst ja einen neuen generischen Typen definieren, also muß das auch als eigenständiger Typ (neue Klassendefinition) deklatiert werden.

"Einen" Alias für mehrere Klassen kannst du so eh nicht definieren.

Ob sowas
Delphi-Quellcode:
type TKanne<xxx> = TSpeziellerFrame<xxx>;
geht, also wirklich ein Alias, weiß ich jetzt nicht, oder ob man da auch
Delphi-Quellcode:
type TKanne<xxx> = class(TSpeziellerFrame<xxx>);
machen muß.


Dieser Alias
Delphi-Quellcode:
TKanne = TSpeziellerFrame<TObjectList>;
geht allerdings, aber wenn man sowas als Komponente/SubKomponente in der DFM speichern will, also auf den Formdesigner legen,
dann darf es kein Alias sein, sondern muß als neuer Typ
Delphi-Quellcode:
TKanne = class(TSpeziellerFrame<TObjectList>);
verpackt werden, da gültige "Bezeichner" für die Klassenverwaltung und den DFM-Reader keine < und > enthalten dürfen.

hzzm 14. Mai 2018 12:08

AW: Generisches Alias von TFrame
 
Ok, vielen Dank!

So langsam gehen mir die Delphi-Generics auf den Keks, alles muss man nachher trotzdem manuell aufbroeseln. Da kann ich auch direkt alles ausschreiben, wenns immer an exakt den Ecken haengenbleibt, an denen Generics den Code vereinfachen/verallgemeinern wuerden... vielleicht habe ich da auch nur generell eine falsche Erwartungshaltung bzgl. generics, aber ich dachte das aus anderen OO-Sprachen etwas flexibler zu kennen.

Zacherl 14. Mai 2018 14:23

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von hzzm (Beitrag 1402040)
So langsam gehen mir die Delphi-Generics auf den Keks, alles muss man nachher trotzdem manuell aufbroeseln. Da kann ich auch direkt alles ausschreiben, wenns immer an exakt den Ecken haengenbleibt, an denen Generics den Code vereinfachen/verallgemeinern wuerden... vielleicht habe ich da auch nur generell eine falsche Erwartungshaltung bzgl. generics, aber ich dachte das aus anderen OO-Sprachen etwas flexibler zu kennen.

Ja, die Delphi Generics sind tatsächlich nur begrenzt nützlich und in keinem Fall mit anderen Sprachen vergleichbar. Das liegt primär daran, dass der Compiler deine Funktionen IMMER generiert und zwar so, dass sie theoretisch für jeden Typ lauffähig wären. Dadurch muss man sehr viel mit RTTI, "schwarzer Magie" und unsicheren Casts arbeiten. Bei anderen Sprachen wie C++ z.B. wird zur Compile-Time geschaut mit welchen Typen eine generische Funktion überhaupt aufgerufen wird und nur diese entsprechenden Varianten werden dann auch erzeugt. Im Zusammenspiel mit Template Spezialisierungen benötigt man dann absolut keine zusätzliche Laufzeitbehandlung.

Sowas wünsche ich mir für Delphi ja nach wie vor, aber ich befürchte dass wird ein Wunschtraum bleiben.

hzzm 15. Mai 2018 06:49

AW: Generisches Alias von TFrame
 
Warum meckert er denn hier schon wieder:
Delphi-Quellcode:
type
  TObstKorb<T: TFrucht> = class
    procedure Essen; virtual; abstract;
  End;

  TBananenKorb = class(TObstKorb<TBanane>)
    procedure Essen; override;
  End;

[...]
begin
  AKorb := TObstKorb<TBanane>.Create;
  AKorb.Essen; // abstrakter Fehler

  AKorb := TBananenKorb.Create;
  AKorb.Essen; // funktioniert
end;
In FreePascal gaebe es ja glaube ich
Delphi-Quellcode:
TBananenKorb = specialize TObstKorb<TBanane>;
. Wie deklariere ich denn die Spezialisierung in Delphi ohne sie abzuleiten?

freimatz 15. Mai 2018 07:17

AW: Generisches Alias von TFrame
 
Er meckert weil AKorb ein TObstKorb<TBanane> ist und dort ist Essen abstract. Ich würde da einen Fehler erwarten.

Wozu willst du eine Spezialisierung? Ich leite immer ab wenn ich es brauche.

So ganz kann ich Deine Probleme leider nicht nachvollziehen. Mich nerven die zwar auch, ab an anderen Stellen wie z.b., dass es keine contraints für Aufzählungstypen gibt.
Wie verwenden gerne Generics (gerade gesucht - an insgesammt 2168 Stellen)

hzzm 15. Mai 2018 07:36

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von freimatz (Beitrag 1402114)
Wozu willst du eine Spezialisierung? Ich leite immer ab wenn ich es brauche.

Wenn
Delphi-Quellcode:
TObstKorb<TBanane>.Create
funktionieren wuerde, koennte ich in einer generischen Funktion in Abhaengigkeit von T a la
Delphi-Quellcode:
constructor TProgrammModel<T>.Create;
begin
  Data := TObstKorb<T>.Create;
end;
die Generik weiterreichen. Das waere doch praktisch, oder?
So wie es aussieht, muss ich aber in jeder generischen Ebene dann so einen Schei*dreck wie
Delphi-Quellcode:
constructor TProgrammModel<T>.Create;
var
  AInfo: PTypeInfo;
  AInfoData: PTypeData;
  tkString: String;
begin
  AInfo := System.TypeInfo(T);
  AInfoData := GetTypeData(AInfo);
  tkString := TypInfo.GetEnumName(System.TypeInfo(T), Ord(AInfoData^.OrdType));

  if tkString = 'tkBanane' then
    AKorb := TBanenenKorb.Create
  else if tkString = 'tkApfel' then
    AKorb := TApfelKorb.Create;
end;
machen.
Erst so kann ich AKorb<T: TFrucht> wirklich generisch verwenden?! Und das in jeder generischen Hierarchie-Ebene?
JESUS CHRIST, please kill me.

Oder uebersehe ich da jetzt massiv was...

freimatz 15. Mai 2018 08:32

AW: Generisches Alias von TFrame
 
Oder ich...
Ich wüsste jetzt woher der compiler wissen soll dass Du nicht TObstKorb<TBanane> sondern TBananenKorb haben willst.
Vielleicht vergisst Du mal die Generics und beschreibst mal welches Anwender-Problem Du lösen willst.

hzzm 15. Mai 2018 12:28

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von freimatz (Beitrag 1402122)
Vielleicht vergisst Du mal die Generics und beschreibst mal welches Anwender-Problem Du lösen willst.

Nachdem ich meine Struktur nun wieder ein ganzes Stueck von generics weggebracht habe, versuche ich mal mein Problem grundsaetzlich und vereinfacht zu beschreiben:

Ich habe 2 Objekt-Typen (nennen wir die Typen mal A1 und A2), die ein paar gleiche und ein paar unterschiedliche Variablen und Funktionen besitzt.
Daher erben sie die allgemeinen Eigenschaften vom Typ A.
Die Eigenschaften, die gleich sind (von A geerbt), werden von vielen anderen Units im Programm benoetigt und manipuliert.
Das ganze Programm verwendet insgesamt nur entweder A1 oder A2, nie beide Typen.

Ich habe ein Adapter-Objekt, das die meisten Manipulationen (sowohl Typ A, A1 und A2) daran vornimmt. Die anderen Units benoetigen immer nur Typ A allgemein, nie die Eigenschaften von A1 und A2.

Daher hat mein Adapter einen Getter, der Typ A rausgibt, aber auch viele andere Getter, die einzelne A-Eigenschaften an andere Units rausgeben.

Ich will vermeiden, dass ich 2 unterschiedliche A1 A2 im Adapter ablege, sprich vermeiden, dass ich alle Getter/Setter/etc des Adapters zwiespalten muss, obwohl nahezu identischer Code ausgefuehrt wird.

himitsu 15. Mai 2018 12:53

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von hzzm (Beitrag 1402111)
In FreePascal gaebe es ja glaube ich
Delphi-Quellcode:
TBananenKorb = specialize TObstKorb<TBanane>;
. Wie deklariere ich denn die Spezialisierung in Delphi ohne sie abzuleiten?

Keine Ahnung was das specialize in FP sein soll.

Ist das sowas wie type?
Delphi-Quellcode:
type
  TAbc = TXyz; // Alias
  TAbc = type TXyz; // neuer Typ / eigene RTTI <<<<<<<<

  TAbc = class(TXyz); // Ableitung/Vererbung

Stevie 15. Mai 2018 13:16

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von himitsu (Beitrag 1402141)
Zitat:

Zitat von hzzm (Beitrag 1402111)
In FreePascal gaebe es ja glaube ich
Delphi-Quellcode:
TBananenKorb = specialize TObstKorb<TBanane>;
. Wie deklariere ich denn die Spezialisierung in Delphi ohne sie abzuleiten?

Keine Ahnung was das specialize in FP sein soll.

Specialize ist die "pascalishe" Syntax für Generics, die sich die FPC devs ausgedacht haben - einfach mal in die Doku schauen: http://wiki.freepascal.org/Generics

Hat aber kaum mit dem Problem hier zu tun, dass abhängig von einem Typen von T eine abstrakte Methode plötzlich was ausführen könnte. Polymorphie hat in dem Zusammenhang nix mit Generics zu tun.

Generics sind prinzipiell dafür da, ebend unabhängig vom Typen einen Algorithmus auszuführen und nicht kontextuell etwas anderes (wenn T Banane ist, das, wenn es es Apfel ist, etwas anderes).

Allerdings kann man sofern man eh schon einen constaint (
Delphi-Quellcode:
TProgrammModel<T: TFrucht>
) hat mit einfachen Mitteln prüfen:

Delphi-Quellcode:
constructor TProgrammModel<T>.Create;
begin
  if TypeInfo(T) = TypeInfo(TBanane) then
    fKorb := TKorb<T>(TBananenKorb.Create)
  else if TypeInfo(T) = TypeInfo(TApfel) then
    fKorb := TKorb<T>(TApfelKorb.Create);
end;

hzzm 15. Mai 2018 13:45

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von Stevie (Beitrag 1402149)
Generics sind prinzipiell dafür da, ebend unabhängig vom Typen einen Algorithmus auszuführen und nicht kontextuell etwas anderes

Das trifft ja ziemlich genau meine letzte allgemeine Problem-Beschreibung:
Ich benoetige ein Objekt, das entweder ein TApfel (/A1) oder eine TBanane (/A2) sein kann und will darauf unabhaengig vom Typ meine allgemeinen Algorithmen ausfuehren (A-manipulierend, A-Rausgebend Getter etc.) eben ohne explizit alles in TApfel- und TBanane-Prozeduren (separate private TBanane und TApfel im Adapter) spalten zu muessen.

Also vermute ich mal, dass ich zu Recht zu generics gegriffen habe.
Das Problem ist nur, dass ich meinen Adapter, mein Model und alles was in Abhaengigkeit (oder eher Unabhaengigkeit) von TApfel oder TBanane handeln will, natuerlich auch Generisch deklarieren moechte. Denn dann erstelle ich mir auf oberster Ebene festlegend einfach einen
Delphi-Quellcode:
ObstAdapter := TObstAdapter<TBanane>.Create;
oder eben
Delphi-Quellcode:
TObstAdapter<TApfel>.Create;
, der wiederum entsprechend entweder einen TApfel oder eine TBanane in sich erstellt usw.

In Wirklichkeit sind da noch ein paar generisch abhaengige Ebenen dazwischen, aber wenn eine geht, gehen alle. Hauptsache nicht alles ausschreiben oder immer um <T> rumanalysieren (wobei die Loesung von Stevie noch einigermassen ertraeglich scheint). Das war meine Erwartung, das <T> einfach runterreichen zu koennen...

himitsu 15. Mai 2018 14:55

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von Stevie (Beitrag 1402149)
Specialize ist die "pascalishe" Syntax für Generics, die sich die FPC devs ausgedacht haben - einfach mal in die Doku schauen: http://wiki.freepascal.org/Generics

Nja, was sagt denn der ClassName von TBananenKorb?

Delphi-Quellcode:
uses
  TypInfo,
  Generics.Collections;

type
  TTest1 = TList<Integer>;
//TTest2 = type TList<Integer>; // [DCC Fehler] E2574 Instantiierter Typ kann nicht für TYPE-Typdeklaration verwendet werden
  TTest2 = type TList;
//TTest3 = specialize TList<Integer>;
  TTest4 = class(TList<Integer>);

procedure TForm1.FormCreate(Sender: TObject);
begin
  ShowMessage('TypeName + ClassName + ParentClassName = Type<>SourceType' + sLineBreak
    + PTypeInfo(TypeInfo(TTest1)).Name + ' + ' + TTest1.ClassName + ' + ' + TTest1.ClassParent.ClassName + ' = ' + BoolToStr(TypeInfo(TTest1) = TypeInfo(TList<Integer>), True) + #10
    + PTypeInfo(TypeInfo(TTest2)).Name + ' + ' + TTest2.ClassName + ' + ' + TTest2.ClassParent.ClassName + ' = ' + BoolToStr(TypeInfo(TTest2) = TypeInfo(TList{<Integer>}), True) + #10
  //+ PTypeInfo(TypeInfo(TTest3)).Name + ' + ' + TTest3.ClassName + ' + ' + TTest3.ClassParent.ClassName + ' = ' + BoolToStr(TypeInfo(TTest3) = TypeInfo(TList<Integer>), True) + #10
    + PTypeInfo(TypeInfo(TTest4)).Name + ' + ' + TTest4.ClassName + ' + ' + TTest4.ClassParent.ClassName + ' = ' + BoolToStr(TypeInfo(TTest4) = TypeInfo(TList<Integer>), True));

  // TypeName + ClassName + ParentClassName = Type<>SourceType
  // TList<System.Integer> + TList<System.Integer> + TEnumerable<System.Integer> = True
  // TTest2 + TList + TObject = False
  // TTest4 + TTest4 + TList<System.Integer> = False
end;
Code:
TypeName              + ClassName             + ParentClassName             = Type<>SourceType

TList<System.Integer> + TList<System.Integer> + TEnumerable<System.Integer> = True
TTest2                + TList<System.Integer> + TEnumerable<System.Integer> = False  (wenn es mit TList<> gegangen wäre)
TTest3 ?
TTest4                + TTest4                + TList<System.Integer>       = False

himitsu 15. Mai 2018 15:05

AW: Generisches Alias von TFrame
 
Delphi-Quellcode:
type
  TSpeziellerFrame<T2> = class(TFrame)
    [...]
  End;

  TKanne<T1> = TSpeziellerFrame<T1>;
Hab mal das T unterschiedlich benann, als T1 und T2, damit man besser sieht, was direkt zusammen hängt.



Zitat:

TKanne<TObjectList> = class( TSpeziellerFrame; ) // ohne class() kompilierts gar nicht
Wegen dem Semikolon?

Oder was soll da nicht gehn?
Es wäre bestimmt hilfreich, wenn jemand (ich schau jetzt mal niemanden speziellen an) bei sowas die Fehlermeldung kopieren würde. :stupid:


PS: Vom Verständnis her, macht es sich IMHO ungünstig, wenn bei
Delphi-Quellcode:
type TIrgendwas<Bezeichner> = ...;
der "Bezeichner" genau wie ein "existierendet" Typ/Klasse benannt wird ... Verwechslungsgefahr.

hzzm 15. Mai 2018 17:39

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von himitsu (Beitrag 1402176)
Es wäre bestimmt hilfreich, wenn jemand (ich schau jetzt mal niemanden speziellen an) bei sowas die Fehlermeldung kopieren würde. :stupid:

Der Semikolon-Fehler war nur im Beispiel, ich habe den Code leider schon laenger nicht mehr so drin.

Ich hab jetzt alles nochmal 10x hin- und hergedreht und denke einfach, ich muss einen Strukturfehler bei den generischen Definitionen machen.
Das kann doch nicht sein, dass das nicht geht. Ich nehme noch einen Anlauf und versuche, meine Struktur zwar simpel, aber so genau wie moeglich darzustellen.

Vielen Dank auf jeden Fall schonmal fuer Eurer aller Bemuehungen!
Delphi-Quellcode:
unit Schritt;

interface

uses
  Zugabe, SysUtils, CleanFloats;

type
  PSchritt = ^TSchritt;
  TSchritt = class
    Temperatur,
    Zeit,
    Gewicht: String[5];

    Zugaben: TZugaben;
  public
    procedure WriteToStream(Offset: Word); virtual; abstract;
    procedure ReadFromStream(Offset: Word); virtual; abstract;
  End;
  TSchritte = TArray<TSchritt>;

  PKSchritt = ^TKSchritt;
  TKSchritt = class(TSchritt)
    Breite,
    Wasser: String[5];
  public
    procedure WriteToStream(Offset: Word); override;
    procedure ReadFromStream(Offset: Word); override;
  End;
  TKSchritte = TArray<TKSchritt>;

  PMSchritt = ^TMSchritt;
  TMSchritt = class(TSchritt)
    Viskositaet,
    Intervall: String[5];
  public
    procedure WriteToStream(Offset: Word); override;
    procedure ReadFromStream(Offset: Word); override;
  End;
  TMSchritte = TArray<TMSchritt>;
 
 
  TZugabe = packed Record
    Name: String[40];
    Menge: String[5];
    Einheit: String[5];
  end;
  TZugaben = TArray<TZugabe>;
Delphi-Quellcode:
unit Rezept;

interface

uses
  Schritt, Zugabe, Hashes;

type
  TRezept<T: TSchritt> = class
    Dateiname: String[70];
    Name,
    Gruppe,
    Datum: String[40];
    Schritte: TArray<T>;
    procedure SchrittLoeschen(const Index: Integer);
    procedure ReadCSV(Dateiname: String); virtual; abstract;
    procedure WriteCSV(Dateiname: String); virtual; abstract;
    procedure LeereSchritt(var Index: Integer); virtual; abstract;
  End;

  PKRezept = ^TKRezept;
  TKRezept = class(TRezept<TKSchritt>)
    procedure ReadCSV(Dateiname: String); override;
    procedure WriteCSV(Dateiname: String); override;
    procedure LeereSchritt(var Index: Integer); override;
  End;

  PMRezept = ^TMRezept;
  TMRezept = class(TRezept<TMSchritt>)
    procedure ReadCSV(Dateiname: String); override;
    procedure WriteCSV(Dateiname: String); override;
    procedure LeereSchritt(var Index: Integer); override;
  End;
Delphi-Quellcode:
unit Programm;

interface

uses
  SysUtils, ExtCtrls, Rezept, Schritt, Vcl.Forms, Observer, KProgrammView, MProgrammView;

type
  TProgrammModel<T: TSchritt> = class
  public
    Rezept: TRezept<T>;
//    Rezept: TKRezept; // So geht es, generisch nicht!
    constructor Create{(AOwner: TComponent)};
  End;

  TProgrammAdapter<T: TSchritt> = class(TInterfacedObject, IProgrammAdapter)
  private
    Model: TProgrammModel<T>;
    IView: IProgrammView;
  public
    Notifier: TObserverSubject;
    constructor Create(AOwner: TComponent; IAView: IProgrammView; AModel: TProgrammModel<T>);
    procedure WriteToStream(Sender: TObject);
    procedure ReadCSV(Filename: String);
    procedure ScaleIngredients(Percent: Integer);
    function GetRecipeName: String;
    function GetRecipeFilename: String;
    procedure SetRecipe(ARezept: TRezept<T>);
  End;
 
implementation

constructor TProgrammAdapter<T>.Create(AOwner: TComponent; IAView: IProgrammView; AModel: TProgrammModel<T>);
begin
  IView := IAView;
  Steps := IView.GetSteps;
  Model := AModel;
end;

procedure TProgrammAdapter<T>.ReadCSV(Filename: String);
begin
//  if Model.Rezept <> nil then
//    Model.Rezept.Free;
//  if TypeInfo(T) = TypeInfo(TKSchritt) then
//    Model.Rezept := TRezept<TKSchritt>.Create
//  else if TypeInfo(T) = TypeInfo(TMSchritt) then
//    Model.Rezept := TRezept<TMSchritt>.Create;

  Model.Rezept.ReadCSV(Filename); // Abstrakter Fehler!
end;

Stevie 16. Mai 2018 09:18

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von hzzm (Beitrag 1402195)
Delphi-Quellcode:
unit Rezept;

interface

uses
  Schritt, Zugabe, Hashes;

type
  TRezept<T: TSchritt> = class
    Dateiname: String[70];
    Name,
    Gruppe,
    Datum: String[40];
    Schritte: TArray<T>;
    procedure SchrittLoeschen(const Index: Integer);
    procedure ReadCSV(Dateiname: String); virtual; abstract;
    procedure WriteCSV(Dateiname: String); virtual; abstract;
    procedure LeereSchritt(var Index: Integer); virtual; abstract;
  End;

  PKRezept = ^TKRezept;
  TKRezept = class(TRezept<TKSchritt>)
    procedure ReadCSV(Dateiname: String); override;
    procedure WriteCSV(Dateiname: String); override;
    procedure LeereSchritt(var Index: Integer); override;
  End;

  PMRezept = ^TMRezept;
  TMRezept = class(TRezept<TMSchritt>)
    procedure ReadCSV(Dateiname: String); override;
    procedure WriteCSV(Dateiname: String); override;
    procedure LeereSchritt(var Index: Integer); override;
  End;

Zitat:

Zitat von Stevie (Beitrag 1402149)
Hat aber kaum mit dem Problem hier zu tun, dass abhängig von einem Typen von T eine abstrakte Methode plötzlich was ausführen könnte. Polymorphie hat in dem Zusammenhang nix mit Generics zu tun.

Ich seh in dem Code nich die Stelle, wo du die Rezept Instanz erstellst, aber gemäß dieser Unit oben bist du dort nicht mehr generisch, sondern leitest von einer generischen Spezialisierung ab, da die generische Klasse nunmal abstrakte Methoden hat - deshalb habe ich meinen Satz von vorher hier nochmal zitiert.

hzzm 16. Mai 2018 14:22

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von Stevie (Beitrag 1402245)
Ich seh in dem Code nich die Stelle, wo du die Rezept Instanz erstellst, aber gemäß dieser Unit oben bist du dort nicht mehr generisch, sondern leitest von einer generischen Spezialisierung ab, da die generische Klasse nunmal abstrakte Methoden hat - deshalb habe ich meinen Satz von vorher hier nochmal zitiert.

Verstehe.
Gemaess meinem Kommentar im Code
Delphi-Quellcode:
// Rezept: TKRezept; // So geht es, generisch nicht!
, kann ich das Model.Rezept als TKRezept deklarieren und mit
Delphi-Quellcode:
TKRezept.Create;
initialisieren, dann funktioniert natuerlich alles (solange der ProgrammAdapter als TProgrammAdapter<TKSchritt> erstellt wird).

Aber das widerspricht ja dem Zweck dieser generischen Struktur, ich will ja auch das Rezept in generischer Abhaengigkeit vom Rest erstellen. Genau das ist der Punkt, an dem ich scheitere; wenn ich im Model 2 Variationen,
Delphi-Quellcode:
KRezept: TKRezept;
und
Delphi-Quellcode:
MRezept: TMRezept;
ablegen muss, die ich konditional bestelle, bin ich ja in genau meiner Zwickmuehle, dass ich viel code zwiespalten muss, obwohl er eigentlich gleich ist. Eine meiner Anfangs-Motivationen zu generics zu greifen.

Gibt es zu diesem Problem innerhalb der Delphi generics ueberhaupt eine Loesung?
Delphi-Quellcode:
constructor TProgrammModel<T>.Create;
begin
  // Rezept := TKRezept.Create; // geht (Deklaration auch als Rezept: TKRezept;)
  // Rezept := TKRezept.Create; // scheitert bei Deklaration als Rezept: TRezept<T>; natuerlich
  Rezept := TRezept<T>.Create; // geht wie besprochen nicht: Abstrakte Fehler
end;

freimatz 16. Mai 2018 14:36

AW: Generisches Alias von TFrame
 
Nein, innerhalb der Delphi Generics nicht. Dazu ist dann die Polymorphie da.

Stevie 16. Mai 2018 15:23

AW: Generisches Alias von TFrame
 
Irgendwo in der Struktur muss ein Teil rein, was anhand des konkreten Typs von T die richtige nicht generische Klasse zum Lesen/Speichern/Whatever erstellt, sofern dieser Code nicht über einen generischen Algo gelöst werden kann. Ich würde mir also überlegen, das CSV Zeugs nicht per Ableitung sondern Aggregation zu koppeln.

Ja, irgendwo im generischen Code muss dann eine if-then-else "Leiter" wie zuvor schon gezeigt rein.

Die Aggregation kann dann per API die Basisklasse nutzen aber je nach Implementierung weiß sie dann, dass die TFrucht Instanzen, die da rein oder raus gehen Äpfel oder Bananen sind.

Aus Erfahrung würd ich dir raten, das Design nochmal zu überdenken und genau zu schauen, wo du strikte Typensicherheit haben willst und wo du lieber mit einer nicht generischen Basisklasse arbeitest die auf Instanzen von TSchritt arbeiten. Man kann dann auch problemlos eine sehr dünne generische Schicht auf eine solche nicht generische Klasse oben drauf setzen (oder per Interface implementieren), so dass entsprechende Consumer typensicher arbeiten. Tiefe generische Hierarchien, bei denen dann noch die Logik abhängig vom generischen Typenparameter ist, enden selten gut.

Uwe Raabe 16. Mai 2018 15:44

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von Stevie (Beitrag 1402292)
Ja, irgendwo im generischen Code muss dann eine if-then-else "Leiter" wie zuvor schon gezeigt rein.

Ohne das jetzt näher analysiert zu haben - wäre das nicht was für das Visitor-Pattern?

Stevie 16. Mai 2018 16:05

AW: Generisches Alias von TFrame
 
Zitat:

Zitat von Uwe Raabe (Beitrag 1402294)
Zitat:

Zitat von Stevie (Beitrag 1402292)
Ja, irgendwo im generischen Code muss dann eine if-then-else "Leiter" wie zuvor schon gezeigt rein.

Ohne das jetzt näher analysiert zu haben - wäre das nicht was für das Visitor-Pattern?

Dafür müsste man der overload resolution in Generics vertrauen, und das tu ich nicht.

Edit: Hast recht, ich hab verkehrt herum gedacht, aber so sollte das funktionieren (auf Erstellen von Objekten wo nicht benötigt hab ich für das Beispiel verzichtet):

Delphi-Quellcode:
{$APPTYPE CONSOLE}

type
  TFruchtKorbFactory = class;

  TFrucht = class
    function GibFruchtKorb(const factory: TFruchtKorbFactory): TObject; virtual; abstract;
  end;

  TBanane = class(TFrucht)
    function GibFruchtKorb(const factory: TFruchtKorbFactory): TObject; override;
  end;

  TApfel = class(TFrucht)
    function GibFruchtKorb(const factory: TFruchtKorbFactory): TObject; override;
  end;

  TFruchtKorbFactory = class
    function CreateInstance(const banane: TBanane): TObject; overload;
    function CreateInstance(const apfel: TApfel): TObject; overload;
  end;

  TGenericDings<T: TFrucht, constructor> = class
    procedure Wuppdi;
  end;

{ TBanane }

function TBanane.GibFruchtKorb(const factory: TFruchtKorbFactory): TObject;
begin
  Result := factory.CreateInstance(Self);
end;

{ TApfel }

function TApfel.GibFruchtKorb(const factory: TFruchtKorbFactory): TObject;
begin
  Result := factory.CreateInstance(Self);
end;

{ TFruchtKorbFactory }

function TFruchtKorbFactory.CreateInstance(const apfel: TApfel): TObject;
begin
  Writeln('erstelle fruchtkorb für apfel');
end;

function TFruchtKorbFactory.CreateInstance(const banane: TBanane): TObject;
begin
  Writeln('erstelle fruchtkorb für banane');
end;

{ TGenericDings<T> }

procedure TGenericDings<T>.Wuppdi;
var
  frucht: T;
  factory: TFruchtKorbFactory;
begin
  frucht := T.Create; // das hier wird für den virtual dispatch von GetWhatever benötigt
  frucht.GibFruchtKorb(factory);

  // Was hier nicht gehen würde wäre: factory.CreateInstance(frucht);
end;

var
  apfeldings: TGenericDings<TApfel>;
  bananendings: TGenericDings<TBanane>;
begin
  apfeldings.Wuppdi;
  bananendings.Wuppdi;
end.


Alle Zeitangaben in WEZ +1. Es ist jetzt 01:47 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz