in reply to Re: Refactor method calls or not?
in thread Refactor method calls or not?

You don't need to change method calls, just make the old methods wrappers for the new super-method. This way the code stays readable (and you don't need to make many changes) but the methods do not duplicate code. Mine is the voice if INexperience though. :)

Replies are listed 'Best First'.
(ichimunki) re x 3: Refactor method calls or not?
by ichimunki (Priest) on Jan 19, 2002 at 04:27 UTC
    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}.

      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.


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