Einzelnen Beitrag anzeigen

alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#4

Re: Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 09:53
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
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat