Generics und Enums

[bernau]

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:

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.

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.

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

Delphi-Quellcode:

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

[Dejan Vu]

Hatte ich ganz vergessen:-) Danke Günni.

[bernau]

Zitat:

Zitat von Dejan Vu (Beitrag 1315546)

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.

Delphi-Quellcode:

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:

Zitat von Dejan Vu (Beitrag 1315546)

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.

[Dejan Vu]

Ich sehe auch keinen Beitrag, der Enums als 'per se schlecht' darstellt. Ich sehe nur Beiträge, die zeigen, das es auch anders geht. Ein Beitrag (meiner) behauptet, das die Verwendung von Enums ein Indiz für unsauberen Code sind. Ein Indiz. Mehr nicht.

Als Faustregel kann gelten: Wenn mit einem Enum (oder Konstanten) an mehreren Stellen im Code Logik ausgeführt wird (das können IF- oder CASE-Schleifen:mrgreen: Anweisungen sein), sollte eine Zusammenfassung der verstreuten Logik und die Verwendung einer Fabrik in Betracht gezogen werden.

Wir haben z.B. eine alte Datenbank, bei der qualitative Merkmale ('Lookup') mit Buchstabencodes, Nummern usw. kodiert werden. Grauenvoll, aber ok. In Delphi (zumindest den alten Dialekten) würde ich dafür Konstanten nehmen, also z.B.

Delphi-Quellcode:

Const
  Gender_Male='M';
  Gender_Female='F';
  Gender_Unknown='N';
  Gender_Bisexual = 'B';
  ...

In C#, mit dem wir arbeiten, kann ich auch Enums verwenden. Wir haben vereinbart, die Repräsentation in der Datenbank über ein Attribut zu spezifizieren:

Code:

public enum GenderType {
  [Representation("M")]
  Male,

  [Representation("F")]
  Female,
...
}

Der Code war so vorgegeben. Wir hätten das anders gelöst, können aber mit dem Pattern 'Enums und RepresentationAttribute' leben.

Was wir aber nirgends haben, ist ein Switch- bzw. Case-Statement über das Geschlecht. Wir haben eine 'Gender' Klasse, die die Eigenschaften des spezifischen Geschlechts kapselt. Beim Einlesen einer Person aus der DB wird im ORM die Spalte 'Gender' sofort auf die Genderklasse gemappt, sodaß die Person als 'Gender' kein Enum hat, sondern eben die Klasse. Die Klasse sieht in etwa so aus

Code:

public class Gender {
  public static Gender Male = new Gender (...)
  public static Gender Female = new Gender (...)

  private Gender (...)
...
}

D.h. ich kann keine Instanz von 'Gender' erzeugen, sondern nur die statischen Klassenkonstanten verwenden. Syntaktisch ist das identisch mit einem Enum, nur kann ich kein Switch aufspannen, was wir genauso wollen. Beim Einlesen der Spalte 'Gender' bekomme ich zunächst einen GenderType (also Enum) und anschließend über eine Fabrikmethode eine der statischen Instanzen. Somit kann ich auf Gleichheit prüfen, wenn ich das muss.

D.h. die Enums dienen in diesem Projekt eigentlich nur der Dokumentation und dem Mapping zwischen einer Kodierung (DB-Spalte 'M','F','N' etc.) und einer Semantik ('Gender.Male').

NB: Da unser Geschlecht 'Gender' wie ein Enum aussieht, aber eine Klasse ist, kann ich nun natürlich auch Generics damit definieren. Womit der Kreis zur Eingangsfrage wieder geschlossen ist.

[Daniel]

Das heißt, Du baust für jeden Enum-Wert eine eigene Klasse?

[bernau]

Zitat:

Zitat von Dejan Vu (Beitrag 1315590)

Ein Beitrag (meiner) behauptet, das die Verwendung von Enums ein Indiz für unsauberen Code sind. Ein Indiz. Mehr nicht.

Zitat:

Unter einem Indiz (von lat.: indicare „anzeigen“) wird ein Hinweis verstanden, der für sich allein oder in einer Gesamtheit mit anderen Indizien den Rückschluss auf das Vorliegen einer Tatsache zulässt.

Also erst mal mit einer Behauptung schlecht machen, ohne Konkrete Beispiele zu geben.

Genau so könnte man sagen "Die Verwendung von Delphi ist ein Indiz für unsauberen Code".

Zitat:

Zitat von Dejan Vu (Beitrag 1315590)

Als Faustregel kann gelten: Wenn mit einem Enum (oder Konstanten) an mehreren Stellen im Code Logik ausgeführt wird (das können IF- oder CASE-Schleifen:mrgreen: Anweisungen sein), sollte eine Zusammenfassung der verstreuten Logik und die Verwendung einer Fabrik in Betracht gezogen werden.

Was ja in meinem oberen Beispiel gemacht wurde. Alle Logiken stehen in der Nähe von der Deklaration der Enums.

Zitat:

Zitat von Dejan Vu (Beitrag 1315590)

Wir haben z.B. eine alte Datenbank, bei der qualitative Merkmale ('Lookup') mit Buchstabencodes, Nummern usw. kodiert werden. Grauenvoll, aber ok. In Delphi (zumindest den alten Dialekten) würde ich dafür Konstanten nehmen, also z.B.

Delphi-Quellcode:

Const
  Gender_Male='M';
  Gender_Female='F';
  Gender_Unknown='N';
  Gender_Bisexual = 'B';
  ...

Wenn du nur Konstanten nimmst, dann hast du keinerlei Möglichkeit zu erfahren, wenn eine neue Konstante zugefügt wurde. Enums kann ich iterieren und eine Exception auslösen.

Übrigens

Delphi-Quellcode:

Const
  Gender_Male='M';
  Gender_Female='F';
  Gender_Unknown='N';
  Gender_Bisexual = 'B';
  HairColor_Blond = 'B';
  HairColor_Black = 'L';
  HairColor_Grey = 'G';

Was hier zusammen gehört, weist du natürlich (als Mensch)

Bei Enums weis der Compiler sofort was zusammen gehört.


Ach ja, hier ein haarsträubendes Beispiel:

Delphi-Quellcode:

Const
  Gender_Male='M';
  Gender_Female='F';
  Gender_Unknown='N';
  Gender_Bisexual = 'I';
  ...

Erkenne den Fehler.

[bernau]

Zitat:

Zitat von Dejan Vu (Beitrag 1315583)

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

Habe ich. Meiner Meinung nach wird hier mit Kanonenkugeln auf Spatzen geschossen.

Thema Stadtmusikanten:

Delphi-Quellcode:

TAnimal = (hund, katze, maus, affe, baer);
TAnimalSet = set of TAnimal;
TAnimalStadtMusikant = [hund, maus];

Wenn ich irgendwo ein Case habe, welches nur die Stadtmusikanten behandeln soll, dann schreibe ich folgendes.

Delphi-Quellcode:

if myAnimal in TAnimalStadtMusikant then
  begin
    case myAnimal of
      hund:TrittDenHund;
      maus:VerfuettereDieMaus;
    else
      MachException;
    end;
  end;

Nun wird TAnimal erweitert:

Delphi-Quellcode:

TAnimal = (hund, katze, maus, affe, baer, huhn);

.

Der Code läuft, weil das neue Tier nichts mit den Stadtmusikanten zu tun hat.

Nun werden die Stadtmusikanten erweitert

Delphi-Quellcode:

TAnimalStadtMusikant = [hund, katze, maus];

Der Code wirft eine Exception.



Und nun dein Beispiel aus dem Thread;

Zitat:

Zitat von Dejan Vu (Beitrag 1271669)

Einfaches Beispiel: Pizza.

Delphi-Quellcode:

Type
  TPizza = (Margeritha, Funghi, QuatroStattione, MitWienerWurstUndSenf);

// Anstatt
Case Pizza of
  Margeritha: begin PackdieTomatesoßerauf; UndKäse; end;
  Funghi : begin PackdieTomatesoßerauf; Pilze; UndKäse; end;
  ...
...
  end;
//schreibt man
  PizzaFactory.CreateRecipe(Pizza).BelegDiePizza();
// Und dieser Code ändert sich dann niemals wieder.

Was spricht gegen:

Delphi-Quellcode:

type
  TPizzaToppics = (Tomatensosse, Kaese, Pilze, Salami, Pepperoni);
  TPizzaToppicsSet = set of TPizzaToppics;

const
  TPizzaBrot = [];
  TPizzaMargeritha = [Tomatensosse, Kaese];
  TPizzaFungi = [Tomatensosse, Kaese, Pilze];
  ...

Procedure TPizzaOfen.BelegDiePizza(TPizzaMargeritha);

Nun kannst du die So viele Pizzen zusammenstellen wie du willst. Alle Sorten stehen beisammen.

Der Code Selber muss nicht geändert werden. Ausser wenn neue Toppics hinzu kommen. Aber dann musst du auch bei dir den Code erweitern.

[Dejan Vu]

Nichts. Nur was machst Du mit einer Calzone (die muss noch umgeklappt werden) bzw. der Steinofenpizzamitrauchgeschmack (Da muss man den Holzofen anwerfen)? Natürlich kannst Du das in dem konkreten (Pizza)Fall vermutlich einfacher gestalten. Nur musst Du Dir beim nächsten Problem wieder etwas (anderes) ausdenken. Mit dem Factory-Pattern im Hinterkopf nimmst Du dir dann wieder eine Factory und dein Code wird immer gleich/ähnlich aussehen. D.h. wenn jemand deinen Code warten muss, dann erkennt er: "Ah, ne Factory. Klar, Erweitern = Neues Verhalten in einer Klasse implementieren, Fabrikmethode erweitern, fertig".

Bei einer eigenen Lösung wie Deiner, ist das eben nicht sooo einfach. Klar ist es einfach, aber man muss sich erst reindenken. Das kostet. Zeit. Und so eine auf den ersten Blick einfachere Lösung ist dann vielleicht nicht so flexibel erweiterbar.

Bei der Softwarentwicklung geht es (den meisten) um: Lesbarkeit, Wartbarkeit, Erweiterbarkeit. So ein Factorypattern ist lesbar, weil man es kennt und weil es konkrete Details auslagert. Es ist leicht wartbar, eben weil man es kennt. Und es ist erweiterbar (Skalierbar), weil man es kennt und daher weiß, das immer das gleiche gemacht werden muss, um noch ne Pizza ins Programm aufzunehmen.

Niemand zwingt Dich, Factories oder andere Pattern einzusetzen oder auf Enums, Case-Statements, verteilte Logik etc. zu verzichten.

[Sir Rufo]

Das Pizza-Beispiel ist schlecht, denn niemand würde einen Pizza-Service schreiben, wo die Toppings als Enums deklariert sind.

Kommen wir mal zu diesem Beispiel, eine Ampelschaltung mit der StateMachine (auch die kann erweitert werden):

Delphi-Quellcode:

program Project3;

{$APPTYPE CONSOLE}
{$R *.res}
{$DEFINE USE_ENUMS}

uses
  System.SysUtils,
  Stateless,
  Stateless.Utils;

type
{$IFDEF USE_ENUMS}
{$SCOPEDENUMS ON}
  TState   = ( 
    {} Red, 
    {} RedYellow, 
    {} Yellow, 
    {} Green );
  TTrigger = ( Timer );
{$ELSE}
  TState = type string;

  TStateHelper = record helper for TState
  const
    Red       = 'Red';
    RedYellow = 'RedYellow';
    Yellow    = 'Yellow';
    Green     = 'Green';
  end;

  TTrigger = type string;

  TTriggerHelper = record helper for TTrigger
  const
    Timer = 'Timer';
  end;
{$ENDIF}

  TTrafficLight = TStateMachine<TState, TTrigger>;

  TTrafficLightData = class
  private
    FState: TState;
  public
    property State: TState read FState write FState;
  end;

procedure Test( AData: TTrafficLightData );
var
  LLight: TTrafficLight;
  LIdx  : Integer;
begin
  LLight := TTrafficLight.Create(
    function: TState
    begin
      Result := AData.State;
    end,
    procedure( const s: TState )
    begin
      AData.State := s;
    end );
  try

    LLight.Configure( TState.Red )
    {} .Permit( TTrigger.Timer, TState.RedYellow );
    LLight.Configure( TState.RedYellow )
    {} .Permit( TTrigger.Timer, TState.Green );
    LLight.Configure( TState.Green )
    {} .Permit( TTrigger.Timer, TState.Yellow );
    LLight.Configure( TState.Yellow )
    {} .Permit( TTrigger.Timer, TState.Red );

    Writeln( LLight.ToString );
    for LIdx := 1 to 10 do
      begin
        LLight.Fire( TTrigger.Timer ); // ohne Enum und 'Blue' kommt erst hier die Exception
        Writeln( LLight.ToString );
      end;

  finally
    LLight.Free;
  end;
end;

procedure TestStart;
const
  InitialStateString = 'Blue'; // Wert wird aus der Datenbank gelesen
var
  LData: TTrafficLightData;
begin
  LData := TTrafficLightData.Create;
  try
{$IFDEF USE_ENUMS}
    LData.State := TEnum.ToEnum<TState>( InitialStateString ); // Wirft eine Exception bei 'Blue'
{$ELSE}
    LData.State := InitialStateString; // 'Blue' wird anstandslos akzeptiert
{$ENDIF}
    Test( LData );
  finally
    LData.Free;
  end;
end;

begin
  try
    TestStart;
  except
    on E: Exception do
      Writeln( E.ClassName, ': ', E.Message );
  end;
  Readln;

end.

In diesem (speziellen) Fall bringt mir der Enum den Vorteil, dass fehlerhafte Daten

Delphi-Quellcode:

'Blue'

sehr früh als solche mir um die Ohren fliegen und auch sehr nah an der Quelle des Übels.

Bei der Definition der Konstanten kann man so einen Fehler machen

Delphi-Quellcode:

  TStateHelper = record helper for TState
  const
    Red       = 'Red';
    RedYellow = 'Red'; // CopyPaste-Fehler durch den Programmierer
    Yellow    = 'Yellow';
    Green     = 'Green';
  end;

der sich aber anstandslos kompilieren lässt. Wenn ich Glück habe, fällt dies zur Laufzeit auf, wenn ich Pech habe läuft einfach alles nur Grütze und keiner weiß warum - beten wir, dass wir einen Unittest haben, der diesen Fehler aufdeckt.

Bei einem Enum geht das nicht

Delphi-Quellcode:

TState = ( 
  {} Red, 
  {} Red, // CopyPaste-Fehler durch den Programmierer
  {} Yellow, 
  {} Green );

denn da schreit einen der Compiler direkt beim Kompilieren an.

Zitat:

Zitat von Meine Meinung

Es geht nicht darum, dass Enums besser als Konstanten sind.

Es gibt aber Fälle (s.o.), wo ein Enum besser ist als Konstanten.
Genau wie es Fälle gibt, wo Konstanten besser als Enums sind.
Und es gibt Fälle, da sind weder Enums noch Konstanten angebracht (s. Pizza-Toppings).

Man muss wissen, welche Vor- und Nachteile das eine oder das andere mit sich bringt und dann eine Entscheidung treffen und mit dieser und den daraus resultierenden Nachteilen leben - Refactoring geht ja auch immer.

Ich würde es gerne noch größer und fetter und bunter und noch auffälliger schreiben, aber ich bin hier in den Möglichkeiten durch das Forum beschränkt :stupid:

[Rollo62]

Ich möchte mal anmerken das die Diskussion sehr akademisch ist, und ich die Dinge oft leider praktisch lösen muss.
Natürlich kenne ich die Fallstricke von case etc., aber damit kommte ich oft in einem Tag zur Lösung während wenn ich erst nach einem optimalen Polymorphismus suche bin ich da eine ganze Woche dran.

Das Problem lässt sich oft leider nicht so klar definieren, sondern es muss erstmal analysiert oder noch schlimmer "erarbeitet" werden.
Daher gehe ich so vor das ich, wenn nicht anders lösbar, erstmal Q&D mit case, enum und dem Grundbaukasten rangehe.
Erst dann wenns funktioniert kann ich mir eine ganze Weile anschauen ob das Konzept1 richtig war.
Aber erst wenn ich etwas hinzufügen muss, vielleicht in einem Jahr, würde ich mir das bestehende Konzept1
anschauen und womöglich in Unterklassen bauen, die Logik auseinandereissen oder was auch immer.

Zeit ist ein nicht zu unterschätzender Faktor für mich,
wenn ihr immer alles perfekt theoretisch analysieren könnt: Hut ab.

Z.B. das Beispiel mit der Ampel ist toll strukturiert, das kommt aber vielleicht auch weil jeder
eine Ampel seit 100 Jahren kennt.

Das Pizzabeispiel finde ich z.B. für viele meiner Aufgaben realistischer:
Wir glauben auch das Pizza-Beispiel gut zu kennen:
aber in der Realität kommt dann die geklappte Calzone,
manche möchten Gyros und Speck auf die Pizza,
dann muss die Pizze quadratisch werden um in den Karton zu passen,
dann wieder dreieckig weil es eine neue Designerverpackung gibt,
und drei Monate später kommt ein Flammkuchen und Crepes-AddOn das wir auch noch mit reinpacken müssen,
danach kommt sicher noch kurzfristig der Flammkuchen mit Gyros drauf,
die Pizza sollte sicher auch auch vorgeschnitten sein, usw, usw.

Wenn ich im Vorfeld zu lange versuche das richtige Konzept zu finden werde ich doch meistens
völlig daneben liegen.
(Wohlgemerkt insbesondere bei Aufgaben die bis jetzt noch garnicht richtig bekannt sind,
anders als die Pizza ...).

Ich habe leider immer wieder gesehen das uns die Realität oft überholt,
und viele schöne Theorien brökeln dahin.

Deshalb gehe ich eher pragmatisch vor:
Die neue Aufgabe mal theoretisch analysieren und Konzept1 entwickeln,
wenn danach prinzipiell noch vieles unklar bleibt dann einfach mal klein anfangen und Testen.
Step-by-step vorarbeiten, mit dem Nötigsten (auch mit case, Enum und Kostanten).
Wenns denn rund läuft dann eine Weile produktiv checken ob das Konzept1 noch überall reinpasst
und erst bei der Erweiterung auf Flammkuchen würde ich mich dann sicher genug fühlen ein Konzept2
mit Polymorphismus, optimierten, passenden Patterns etc. dazu aufzustellen.

Für mich, der leider oft schnelle Lösungen produzieren muss, ist das der einfachste Weg.

Natürlich ist das nur bedingt optimal für manche Fälle wie z.B. für grosse Teams, Libraries, etc.

Aber in vielen Beiträgen höre ich raus das es nur einen goldenen Weg gibt,
wobei ich eher glaube das viele Wege (und Umwege) nach Rom führen ...

Rollo

[Dejan Vu]

Zitat:

Zitat von Rollo62 (Beitrag 1315685)

Zeit ist ein nicht zu unterschätzender Faktor für mich,
wenn ihr immer alles perfekt theoretisch analysieren könnt: Hut ab.

...Wenn ich im Vorfeld zu lange versuche das richtige Konzept zu finden werde ich doch meistens
völlig daneben liegen.

Daher sind Pattern, und insbesondere das Erkennen, welches Pattern welches Problem löst, so angenehm. Da muss man nicht mehr großartig analysieren: Man verwendet es einfach und ist damit auf der sicheren Seite. Der Code ist ja lesbar, erweiterbar und skalierbar.

Der Hausbauer kann natürlich jede Wand individuell hochziehen, je nach Statikanforderungen unterschiedlich dick, eine aus Stein, die andere aus Ziegeln, oder zur Abwechslung aus Holz und Lehm (die Südseite muss atmungsaktiv sein) usw.

Oder er verwendet Standardmaterialen in Standardabmessungen.

Bei der ersten Variante muss er seinen Kollegen genau erklären, was wie wo wann und warum genauso gebaut werden muss. In der zweiten Variante wissen die Kollegen das schon.

[bernau]

Ich sehe es natürlich so wie Sir Rufo. Jede Lösung hat seine Vor- und Nachteile. Er hat das ja auch "wie immer" mit verständlichen Beispielen belegt.

Was ich nicht mag ist die Pauschalisierung. Nehme man folgende Aussage.

Zitat:

Zitat von Dejan Vu (Beitrag 1315227)

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.

Der erste Satz mag ja noch stimmen. Der nachfolgende Satz ist absolut unbegründet und Wertlos. Mir fehlt da einfach die Begründung.

Genau so bei folgenden Aussagen.

Zitat:

Zitat von Dejan Vu (Beitrag 1315518)

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

@Dejan Vu: Viele deiner Beiträge sind zwar philosophisch sehr Wertvoll. Bringen aber in der Praxis nichts, weil diese so abstrakt sind und so viele pauschale negative Aussagen haben die in der Regel nicht konkret begründet sind. Bei deinen Beispielen fehlt mir leider der Aha-Effekt. Damit will ich dich nicht persönlich angreifen, sondern mehr konkrete Beispiele für deine Behauptungen bekommen. Vielleicht verstehe ich (und andere) dann eine Beiträge besser .

Übrigens halte ich es so wie Rollo62. Mann muss nicht immer alle möglichen Eventualitäten berücksichtigen. Manchmal ist die spontane schnelle Lösung die bessere Wahl. Oft gibt es während der Programmierphase wieder ganz andere Anforderungen (die man ja selber nicht beeinflussen kann). Dann kann man den Code sowiso nicht einfach erweitern, sondern muss ihn einfach wegschmeißen um dann den optimalen Code zu erzeugen. In vielen Fällen ist man ja auch nur erst einmal der fachfremde Programmierer. Wenn ein neues Projekt angegangen wird, dann verwendet man das Fachwissen, welches man sich beim Programmieren aneignet. Die Sichtweise und das Wissen ändert sich und damit auch der Programmieransatz. Auch deshalb ist der schnelle unkomplizierte Ansatz (manchmal) der Bessere.

Ähm. Ich schweife vom Thema ab. "Generics und Enums" ist für mich hiermit geklärt und der Thread für mich persönlich abgeschlossen.

[Rollo62]

Ich bin natürlich auch ein Fan der reinen Lehre.

Es ist nur leider in der Realität so das ich meine Zeit für banalde Probleme verschwende, wie
z.B. Control zeichnet sich nicht da wo es soll, Click unter letztem ListView sended OnClick,
Bluetooth Verbindung hat Probleme beim Wiederverbinden, usw. usw.

Dafür habe ich noch kein passendes Pattern gefunden.

Für die eigentlich Programmlogik komme ich meist mit dem Grundbaukasten sehr gut klar und wenn
es schön strukturiert ist und ich Zeit übrig habe kann ich auch Patterns, Interfaces, etc. dazupacken.
Das ist aber mehr die Kür für mögliche zukünftige Erweiterungen, und bring kaum konkreten Mehrgewinn.

Im Gegenteil, es ist oft so das ein perfekt designtes Pattern dann nie wieder gebraucht wird.
Ich habe mir daher abgewöhnt als "Hellseher" all zukünftigen Fälle richtig bewerten zu wollen.
Wenn es soweit ist, ist dann immer noch früh genug.

Ich habe eigentlich ein anders "Pattern" entwickelt:
KISS-Prototyp-Pattern:
- erstmal die Machbarkeit zeigen in einem kleiner, mit Grundbausteinen gebauter Lösung.
- dabei etwas mehr über das eigentlich Problem lernen, wenn möglich
- erst beim 2. Anfassen und Erweitern der Lösung würde ich über den Umbau in besser strukturierte Patterns
vorsehen.

Alle vertreter der einen Lehre haben natürlich recht: mit dem von vornherein richtigen Pattern wird das
spätere Ändern und pflegen ein Kinderspiel.
Nur das ich oft feststelle das mein ursprüngliches Pattern gar nicht so optimal war, oder das die
ultra-flexible Erweiterungen in alle Himmelsrichtungen gar nicht mehr gebraucht werden, etc.

Deshalb würde ich mein Vorgehen auch einfach als ein neues "Pattern" beschreiben, und bin damit auch ein
Mitglied im Club der reinen Lehre :-D

Rollo