Es ist immer schwer, bestehende Programme an Extrawünsche anzupassen. Man merkt dabei sofort, wie gut die Architektur der Anwendung ist.
Hier hast Du zudem noch eine ziemlich dämliche Vorgabe, aber es kann ja sein, das es nicht anders geht. Vielleicht ist das Datenbankformat vordefiniert o.ä.
Wenn Du allerdings eine andere Lösung implementieren könntest, würde ich alles daran setzen, diese blöde Funktionsverwurstung in Auftragsnummern zu kicken. Denn transparent und nachvollziehbar ist das nicht. Wird man sich in 2 Jahren noch an die Bedeutung des 2.Buchstabens erinnern? War das nun 'Zuschlag 5%', oder 'Teilweise Rabattierfähig'?
Dein Ansatz mit den Booleanfeldern ist schon mal nicht schlecht, aber bei der nächsten Änderungen (noch eine Option) müsstest Du die Klasse "Auftrag" ja schon wieder aufblähen.
Ich würde dem Auftrag eine Liste von Key-Value-Paaren mitgeben. Dort kannst du Optionen reinpacken, bis der Arzt kommt. Z.B. so:
Delphi-Quellcode:
Type
TAuftrag = Class ...
...
Public
Property Option[Key : String] : Variant Read GetOption Write SetOption;
End;
...
DerAuftrag.Option['IstRabattierfähig'] := 1;
DerAuftrag.Option['Zuschlag'] := 'teilweise';
Damit ist dann Ruhe. Du könntest damit sogar soweit gehen, um im Setter der 'Option'-Eigenschaft die Auftragsnummer wirkllich so zu ändern, wie es gewünscht ist. Aber über
Zitat
Baum-Darstellung
