Generics und Enums

[Sir Rufo]

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

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

[Dejan Vu]

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.

[Rollo62]

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

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

[Dejan Vu]

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.

[Sir Rufo]

Enums und Konstanten haben beide ihre Tücken.

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

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

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.

[Dejan Vu]

Etwas Ähnliches kann Dir mit Enums passieren:

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.

[Der schöne Günther]

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

[bernau]

Zitat von Dejan Vu:

Etwas Ähnliches kann Dir mit Enums passieren:

Delphi-Quellcode:

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

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

Deine Haarsträubenden Beispiele sind aber auch ein bischen an den Haaren herbei gezogen. Wenn du dort einen Zuweisungsfehler machst, dann machst du den auch wo anders.

Enums werden ja auch nicht immer mit zugewiesenen werten benötigt. Eine Gruppe von begrenzten zusammenhängenden Zuständen ist mit Enums perfekt abzubilden.

TLedColor = (LcRed, LcOrange, LcGreen, LcBlue); Wenn ich tippe, werden mir genau diese Farbzustände vorgeschlagen. Alles andere getippte wird mit einem Compilerfehler angezeigt.

Wenn ich Werte mit diesen Enums verwenden möchte, dann schreibe ich eine Funktion

Das in einem Record oder in einem Objekt, dann habe ich alles zusammen.

Delphi-Quellcode:

TLedColorProcs = Record
  class function ItemAsColorValue(aLedColor:TLedColor):Tcolor;
  class function ItemAsColorname(aLedColor:TLedColor):String;
  class function IsAvailableColor(aColot:TColor):boolean;
end;

Dazu ist die Funktionalität von Sets nicht zu verachten.

Delphi-Quellcode:

TLedColorSet = set of TLedColor;

const
  TLedColorCritical = (LcRed, LcOrange);

if myLedColor in TLedColorCritical

Zeig mir eine halbwegs akzeptable Lösung, mit dieser Funktionalität.

Natürlich sollte man bei Case-Statements die Funktionen mit einer Exception absichern, wie Sir Rufo es oben beschrieben hat. Dann noch unittests, welche alle möglichen Enum-Werte übergibt, dann sollte es doch auch nicht so fehleranfällig sein.

[Dejan Vu]

Zitat:

Zitat von Dejan Vu:

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

Deine Haarsträubenden Beispiele sind aber auch ein bischen an den Haaren herbei gezogen.

Das liegt in der Natur von haarsträubenden Beispielen.
Ich bin nur dem Beispiel von Sir Rufo gefolgt und habe ein Beispiel gebracht, welches eine These unterstützt oder eine andere widerlegt. Diese Form der Argumentation hat so seine Tücken, wie ich mit dem haarsträubenden Beispiel belegt habe. Gut, das Du das bestätigt hast.

Lies mal die von Günther verlinkte Diskussion, die behandelt das Thema nochmals.

Wenn Du meinst, das Enums perfekt sind, dann verwende sie eben. Nur musst Du Dich dann nicht wundern, wenn Du in einigen Kreisen kopfschüttelndes Stirnrunzeln erntest und Dich rechtfertigen musst. Niemand sagt, das sie nicht verwendet werden dürfen. Nur... So... Indiz... und so. Ne.

[Daniel]

Wie jedes andere Element passen Enums nicht überall - aber in keinem der verlinkten Beispiele sehe ich ein Argument, warum Enums pe es schlecht sein sollen. Ich sehe nur Beispiele, in denen Enums nicht das Mittel der Wahl sind.