Generics und Enums

[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

[Dejan Vu]

Zitat von Rollo62:

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

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

@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

Rollo