Generics und Enums

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

[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 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 von Dejan Vu:

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 von Dejan Vu:

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 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 von Dejan Vu:

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 von Dejan Vu:

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:

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

TAnimalStadtMusikant = [hund, katze, maus]; Der Code wirft eine Exception.



Und nun dein Beispiel aus dem Thread;

Zitat von Dejan Vu:

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

[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