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

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