> 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
