(ichimunki) re x 3: Refactor method calls or not?

[ichimunki]

Unless Ovid thinks he'll have to go back and differentiate these methods again in the future, changing the calls to the method is probably not much more difficult than a search and replace in the calling code blocks. If he has already bounds-tested and otherwise proofed the data elements, a more generic insert/update method is called for-- and it will be faster to change the calling code than to refactor a long list of unique methods to call the generic method. If he has *not* proofed his values, though, he might want to leave these routines with unique names so that he can validate at this point-- which is probably too late {grin}.

[Ovid]

For the record, I have done bounds checking on everything. I was, however, a bit ambivalent about exactly where to put it. Data validation is primarily done at the untainting level, as much of the data is free-form. There are some specific instances where validation is a bit tighter ("does such and such a key actually exist", for instance, or "do we have a valid date"), but I opted to have that in the calling code rather than in the database API layer. I didn't want to duplicate validation in both the calling code and the API, but I still wound up with some extra validation in the API for really persnickety problems. I think I need to go back and do more reading on system design, though. I'm not quite happy with how everything got laid out.

Side note: as for perrin's node about exception handling, they're handled either in the calling code or in the database parent class (using CGI::Carp. Since this is the largest system that I have build to date, it's been quite a learning experience.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.