Case-Anweisung auf Enumerationstyp. Eines Tages wird der Enumerationstyp erweitert.

[Dejan Vu]

Na in dem Beispiel mit den Tieren aus Bremen wäre das Case-Switch imho noch annehmbar. Deswegen gleich eine Klassenfamilie aufzumachen, wäre dann doch etwas Overkill. Lesbar soll das ja noch bleiben. Aber der Hinweis auf die Pattern ist sicherlich hilfreich (Sobald eine zweites Case ins Spiel kommt oder etwas mehr passiert, als einen Return-Wert zu setzen, sollte man aber ansetzen).

Abschließend vielleicht noch das Stichwort: Factory. Das ist das, was Uwe und Stevie meinen. In der (Klassen)Fabrik wird anhand einer Eigenschaft der Spezialist (also die Klasse) ausgewählt, der die Verarbeitung übernimmt.

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.

Man stelle sich vor, aus der kleinen Klitsche, die 4 Pizzas macht, wird mal eine, die 30 Sorten kann. Dann würde das Case-Statement ziemlich schrottig aussehen, wohingegen bei der Factory alles immer noch so aufgeräumt ist, wie am ersten Tag.

Merke: Mit sauberem Code kaschiert man auch das eigene Chaos (mach ich jedenfalls so)

[Stevie]

Zitat von Dejan Vu:

Bei den Kunden mit den Rabatten würde ich mir auch 2x überlegen, ob ich dafür Ableitungen von Kunden machen würde. Erstens sind das immer noch Kunden und nur weil der heute mal 20% Rabatt bekommt (Geburtstag!) ist das doch kein anderer Kunde, und außerdem würde für den Rabatt wieder eine Strategy passen, unter der Annahme, das es sich bei Rabatt um etwas komplexeres handelt, als nur eine einzelne Zahl.

Ich stelle mir auch lustig vor, dem Kunden zur Laufzeit einen anderen Rabatt zu verpassen: Da müsste ich den Kunden komplett zerstören (also seine Instanz, nicht ihn), nur weil heute sein Geburtstag ist.. Nun ja.

In deinem Beispiel besteht die Rabattberechnung aus mehreren Teilen, der erste Teil, der sich über den Typ des Kunden ergibt (normalo, silber, gold...), also der Rabatt, den er immer bekommt und zusätzlich ich nenns mal temporären Rabatt (weil er Geburtstag hat oder Deutschland 7 Tore geschossen hat, oder...).

Natürlich hinkt das Beispiel wie es Beispiele nunmal tun, denn der flexibelste Weg wäre eine Rabatt Property. Die ermöglicht nämlich auch individuell ausgehandelten Rabatt, den man z.b. in seiner Datenbank pflegt. Aber darum gehts ja in dem Fall nicht, sondern darum, Conditions über Polymorphie zu lösen.

[Dejan Vu]

Na, ich würde auch dann keinen Kunden ableiten, sondern die Strategy verwenden (mit der Factory, fertig).

[nuclearping]

Danke für die Erklärungen. Werde mir das Video mal in Ruhe anschauen. Bei sowas lernt man ja (wie man sieht) nie aus.

[Stevie]

Zitat von Dejan Vu:

Na, ich würde auch dann keinen Kunden ableiten, sondern die Strategy verwenden (mit der Factory, fertig).

Zitat von sahimba:

Zitat von Stevie:

In solch einem Fall hab ich verschiedene TCustomer Nachfahren, die jeweils die GetRabatt Methode überschreiben.

Da fiele mir allerdings als erstes das Strategy Pattern ein.

Wie schon gesagt, das Beispiel hinkt, ein einziger numerischer Wert, der sich unterscheidet, rechtfertigt kaum verschiedene Klassen.
Aber lasst uns ruhig noch nen bisschen auf dem Beispiel rumreiten, bis wir den eigentlichen Sinn davon wieder vergessen haben

[Dejan Vu]

Da hat mal einmal im Leben die Möglichkeit, etwas an Deinen Ausführungen zu kritisieren, und ja ok, dreht sich dabei im Kreis, u aber man muss doch die ganzen Jahre nachholen, und dann wird einem das auch noch madig gemacht.

Das ist echt nicht fair.

Ich schmolle jetzt übrigens, falls es hier Irgendjemanden interessiert.

[Stevie]

Zitat von Dejan Vu:

Da hat mal einmal im Leben die Möglichkeit, etwas an Deinen Ausführungen zu kritisieren, und ja ok, dreht sich dabei im Kreis, u aber man muss doch die ganzen Jahre nachholen, und dann wird einem das auch noch madig gemacht.

Das ist echt nicht fair.

Ich schmolle jetzt übrigens, falls es hier Irgendjemanden interessiert.

Ach, da gibts oft genug Gelegenheiten, du musst sie nur erkennen

Aber mal Quatsch beiseite, das ist natürlich das Problem bei Beispielen, um bestimmte Aspekte zu verdeutlichen, dass es immer Haken gibt und man im Rahmen dieses limitierten Beispielcodes etwas komplett anders lösen würde/könnte. Nur meist ist der Code ja da, um eine bestimmte Sache zu verdeutlichen.
Im übrigen ist das auch ein Kritikpunkt, der von manchen gebracht wird - "ihr mit euren Beispielen, das klappt in der Praxis doch eh alles nicht" (erst Samstag wieder in der Pause von irgendwo aufgeschnappt).

[Dejan Vu]

Das ist ein schönes Thema für eine K&T-Thread (obwohl es fachbezogen und sehr interessant ist): "Wie finde ich einfache Beispiele, anhand derer ich einen Sachverhalt erklären kann, ohne das irgendein Nörgler die in der Luft zerreißt".

Und Nörgler gibt es immer. Irgendwie.

Manchmal bekomme ich es hin, aber manchmal auch nicht, und da bügele ich im Vortrag den Nörgler schon mal mit einem 'Maneuverkritik können wir nachher üben, jetzt bleiben wir beim Thema' und beim 2. Einwand "Das stört jetzt". Meistens reicht es. Der Typ ist zwar beleidigt, aber der Vortrag ist gerettet

Aber wir kommen echt vom Thema ab. Wobei dazu mit 'Factory, Strategy, aber nicht übertreiben' eigentlich alles gesagt ist.