Generics und Enums

[Der schöne Günther]

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

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

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