Ich versuche mich grade an Generics. Da ich viel mit Enums arbeite, habe ich versucht diese beiden Dinge zu kombinieren. Als TypeParameter möchte ich also ein Enum angeben. Das kann ich hervorragend definieren, aber ich kann in einer Funktion diese Parameter nicht auswerten.

Hier mal ein Beispielcode:

zusammenfalten · markieren

Delphi-Quellcode:

unit genericstest;

interface

type
  TblubItems1 = (ti1a, ti1b, ti1c, ti1d, ti1f);
  TblubItems2 = (ti2a, ti2b, ti2c, ti2d, ti2f, ti2g);

type
  TGenericstest<TBlubItems> = class(TObject)
  public
    function count:integer;
    function IndexFromItem(aItem:TBlubItems):integer;
  end;

  TGenericstestBlub1 = class(TGenericstest<TblubItems1>);
  TGenericstestBlub2 = class(TGenericstest<TblubItems2>);

implementation

{ TGenericstest<TBlubItems> }

function TGenericstest<TBlubItems>.count: integer;
begin
  // Was hier rein setzen, um die Anzahl der Items im Aufzählungstyp zu ermitteln
  // Bei TblubItems1 muss das Ergebnis 5 sein.
  // Bei TblubItems2 muss das Ergebnis 6 sein.
end;

function TGenericstest<TBlubItems>.IndexFromItem(aItem: TBlubItems): integer;
begin
  // Was hier rein setzen, um den Index eines Items im Aufzählungstyp zu ermitteln.
  // Bei aItem = ti1a muss das Ergebnis 0 sein.
  // Bei aItem = ti2c muss das Ergebnis 2 sein.
end;

end.

Ich kann diese Objekte Erzeugen und anwenden.

zusammenfalten · markieren

Delphi-Quellcode:

procedure TForm1.BitBtn1Click(Sender: TObject);
var
  lGenericstestBlub1 : TGenericstestBlub1;
  lGenericstestBlub2 : TGenericstestBlub2;
begin
  lGenericstestBlub1 := TGenericstestBlub1.create;
  lGenericstestBlub2 := TGenericstestBlub2.create;

  ListBox1.items.add(inttostr(lGenericstestBlub1.IndexFromItem(ti1a)));
  ListBox1.items.add(inttostr(lGenericstestBlub2.IndexFromItem(ti2b)));

  lGenericstestBlub1.free;
  lGenericstestBlub2.Free;
end;

Aber was nützt mir das, wenn ich in der Funktion IndexFromItem oder Count den übergebenen Typen nicht auswerten kann.

Ich habe schon in einem anderen Beitrag gesehen, das Generics und Enums nicht wirklich zusammen passen sollen. Aber der Beitrag ist von 2010. Vieleicht hat sich ja im Sprachumfang noch etwas geändert.

Nein, hat sich nichts geändert. Du kannst Generics in mehrerer Hinsicht einschränken, aber Enums sind nicht darunter.

Für Enums muss man sich die Informationen über System.TypInfo holen.

Das sieht dann z.B. so ( s. TEnum ) aus.

Generics und Enums passen nicht so recht zusammen. Das ist einer der Gründe, warum man auf Enums (weitestgehend) verzichten könnte und sollte. Ein anderer ist, das man sie einfach kaum braucht.

Hallo Dejan Yu,

das sehe ich aber etwas anders.

Enums und Konstanten verbannen sehr sicher alle "Magic Numbers" aus den Programmen,
und falls sich mal etwas ändern muss kann ich 100% sicher sein das diese Änderungen auch bis
in die hinterste Ecke ankommen (per Kompiler).

Deshalb sind sie für mich unverzichtbar.

Also z.B.:

markieren

Code:

function DemoDingOhneEnums(InVar1 : Integer; InVar2 : String): TDateTime;
begin
  if InVar2 = 'ufo' then
    InVar1 := InVar1 + 1;

  case InVar1 of
    1011:
      Result := DateTime - (TimeZoneInfo.Bias / 60 / 24);
    2012:
      Result := DateTime - ((TimeZoneInfo.Bias + TimeZoneInfo.DaylightBias) / 60 / 24);
    else
      Result := 0;
  end;

end;


function DemoDingMITEnums(InVar1 : Integer; InVar2 : String): TDateTime;
begin
  if InVar2 = CSTR_DEMO1 then
    InVar1 := InVar1 + TIME_ZONE_DELTA;

  case InVar1 of
    TIME_ZONE_ID_STANDARD:
      Result := DateTime - (TimeZoneInfo.Bias / MIN_PER_HOUR / HOURS_PER_DAY);
    TIME_ZONE_ID_DAYLIGHT:
      Result := DateTime - ((TimeZoneInfo.Bias + TimeZoneInfo.DaylightBias) / MIN_PER_HOUR / HOURS_PER_DAY);
    else
      Result := RES_ERROR;
  end;

end;

Die Enums

Zitat:

CSTR_DEMO1
TIME_ZONE_ID_STANDARD:
TIME_ZONE_ID_DAYLIGHT:
MIN_PER_HOUR
HOURS_PER_DAY
RES_ERROR

Machen diese Funktion viel verständlicher und absolut fehlersicher, ich ersetzt mittlerweile fast
alle 0'en und 1'en als Enum oder Konstante (Ok, ok, auch nicht immer).

Aber ich hoffe mein Punkt wird klar:
- Sobald eine Konstante eine spezielle Funktion erfüllt (siehe MIN_PER_HOUR oder RET_ERROR),
macht es für mich sehr viel Sinn dies in Code festzuschreiben.

Änderung wird dadurch ein Kinderpiel auch über zig Module, einfach Enum anpassen und fertig.
Auch bei neu hinzugefügten Enums lassen sich sehr leicht alle möglichen Einflusspositionen suchen.
Von der besseren Lesbarkeit mal ganz zu schweigen.

Und wer dann doch mal an manchen Stellen die Enums als Integrr oder Strings braucht kann
über die Rtti (siehe Sir Rufo) dies mittlerweile sehr einfach umwandeln.

Rollo

Da man nun aber wiederum 'case' Statements nicht verwenden sollte, stimmt es doch wieder

Die Verwendung von Enums ist fast immer ein Indiz für 'schlechte' Programmierung (im Sinne von: OCP). Eine Ausnahme sind Fabrikmethoden bzw. die Registrierung mit einem Enum als Schlüssel. Aber das geht auch mit Konstanten.

Man kann natürlich Enums verwenden, um das magic number Antipattern zu vermeiden. Aber Konstanten sind hier geeigneter, weil sie flexibler sind (unterschiedliche Typen, Wertebereiche etc.).

So, und wenn nun Enums auch durch Konstanten abbildbar sind und Konstanten eh flexibler sind, dann kann ich doch gleich Konstanten verwenden bzw. gibt es keinen Grund mal Enums und dann doch mal wieder Konstanten zu verwenden.

Enums und Konstanten haben beide ihre Tücken.

Ein case auf einem Enum, der alle States berücksichtigen muss sollte immer so aufgebaut sein

markieren

Delphi-Quellcode:

TMyEnum = (a,b,c);

case MyEnum of
  TMyEnum.a : ;
  TMyEnum.b : ;
  TMyEnum.c : ;
else
  raise ENotImplemented.Create(Ord(MyEnum));
end;

sonst hat man ein Problem, wenn der Enum-Type erweitert wird.

Bei der Verwendung von Konstanten habe ich dabei das Problem, dass bei einer Erweiterung die Werte doppelt vergeben kann (was wiederum falsch sein könnte).

markieren

Delphi-Quellcode:

TMyEnum = record
const
  a = 0;
  b = 1;
  c = 2;
  d = 1; // Das ist leider falsch
end;

Sowohl das eine als auch das andere Szenario kann sich fatal auswirken.

Etwas Ähnliches kann Dir mit Enums passieren:

markieren

Delphi-Quellcode:

Type
  TPowerOfTwo=(One=1, Two=2, Four=4, Eight=7);

Wie Du siehst: Haarsträubende Beispiele kann man immer anbringen.

Du verwendest also gerne Konstanten und Enums (wie Konstanten)? Vollkommen ok. Ich verwende nur Konstanten, denn Ich finde Enums überflüssig. So wie vegetarische Tofubratwürste. Trotzdem würde ich welche essen, wenn... obwohl.. Nee.

Enums verwende ich auch (sehr selten) bzw. schreie nicht, wenn ich welche entdecke. Bei Tofubratwürsten hingegen schon. Insofern hinkt der Vergleich.

Als Lese-Tipp am Rande - Vor genau einem Jahr: http://www.delphipraxis.net/181772-c...erweitert.html

Hatte ich ganz vergessen Danke Günni.