|
|
Posted by Josh Whiting on 01/09/05 00:10
> Josh, I am interested in what you mean by "but there may be a better
> overall approach."
(which was in reference to my original question which was: why are you
using a big switch?)
The reason I say that is because, though I'm no expert on application
design, in my own code I've found that whenever I'm tempted to use a big
switch, it's probably a better idea for me to make a class hierarchy. I
just have a hard time imagining a case where a big switch accurately
represents the problem to be solved, since in real life solving problems
is more complicated than a flat set of totally isolated operations.
For example, a while ago I wrote some form validation code for a
classifieds application that used a 50+ case switch to validate incoming
form data, one case for each possible kind of field (make & model,
price, location, color, etc). There was a large amount of overlapping
functionality for similar field types and it was also hard for me to
understand exactly what the start and end goal was for all the cases.
If some common thing needed to be changed, most or all the cases had to
be updated and kept consistent, and by the 45th case my brain is going
to miss something.
Now I'm not suggesting this is what you're doing - this is just bad
design on my part. Currently I'm in the process of implementing a class
hierarchy of fields, where for example the "make_and_model" class
inherits from the "drop_down" parent class, which inherits from the
"basic_field" class, each one extended or overriding it's parents
validate() method. If I need to update the way drop downs validate, I
make a change in the drop_down class and it propagates naturally to all
the instances and subclasses. A much better method than my earlier
switch!
So, because I feel like I've learned a bit personally about avoiding big
switches I was curious about your approach, which I say again could be
perfectly elegant :)
/jw
Navigation:
[Reply to this message]
|