T
Tom Forsmo
hi
In a project I just started in a came across a questionable design, and
I thought I'd ask this group how to improve on it. The simple design was
as follows (as I remember it right now), an Appointment class containing
a list of AppointmentItems (for a case worker). the AppointmentItems was
designed as follows (in uml):
appointmentItem:
...
bool preferMonday;
bool preferTuesday;
bool preferWednesday;
bool preferThursday;
bool preferFriday;
bool preferMorning;
bool preferAfternoon;
its quite obvious that this is bad design, the first alternative I could
think of would be to have a list of preferenceItems instead. But it
might be a bit overkill for this application, also I cant think of many
other preferences that might be applicable. The list would only contain
one or two items, so the extra class and code to process that list and
make decision based on that list might be a bit excessive.
An alternative solution is an enum typed array containing preferences,
but it would not be very much simpler, only a class less.
For both solutions there would have to be logic to process the
preference when used, but I am not sure what would be the best way of
doing that. The only thing that comes to mind is a switch statement, but
that of course depends on how the information would be used (which I am
not sure of). If its to be displayed, it only needs a getDescription(),
but if its for decision making then I am not sure what the best way is.
any comments on what the best design is and what's the best decision
logic, in general for this case, is?
tom
In a project I just started in a came across a questionable design, and
I thought I'd ask this group how to improve on it. The simple design was
as follows (as I remember it right now), an Appointment class containing
a list of AppointmentItems (for a case worker). the AppointmentItems was
designed as follows (in uml):
appointmentItem:
...
bool preferMonday;
bool preferTuesday;
bool preferWednesday;
bool preferThursday;
bool preferFriday;
bool preferMorning;
bool preferAfternoon;
its quite obvious that this is bad design, the first alternative I could
think of would be to have a list of preferenceItems instead. But it
might be a bit overkill for this application, also I cant think of many
other preferences that might be applicable. The list would only contain
one or two items, so the extra class and code to process that list and
make decision based on that list might be a bit excessive.
An alternative solution is an enum typed array containing preferences,
but it would not be very much simpler, only a class less.
For both solutions there would have to be logic to process the
preference when used, but I am not sure what would be the best way of
doing that. The only thing that comes to mind is a switch statement, but
that of course depends on how the information would be used (which I am
not sure of). If its to be displayed, it only needs a getDescription(),
but if its for decision making then I am not sure what the best way is.
any comments on what the best design is and what's the best decision
logic, in general for this case, is?
tom