When I was programming a Form Validator in PHP, when creating new methods, I needed to increase the number of arguments in old methods.
When I was learning Java, when I read that extends is to not touch previously tested, working code, I thought I shouldn’t have increased the number of arguments in the old methods, but overridden the old methods with the new methods.
Imagine if you are to verify if a field is empty in one part of the form, in an other and in yet an other.
If the arguments are different, you’ll overload isEmpty, but, if the arguments are equal, is it right to use isEmpty, isEmpty2, isEmpty3, three classes and one isEmpty per class or, if both are wrong, what should I have done?
So the question is:
If I need different behaviors for a method
isEmptywhich receives the same number arguments, what should I do?If that’s the question then I think you should use:
When they belong to the same logical unit ( they are of the same sort of validation ) but don’t use numbers as version, better is to name them after what they do:
isEmptyUser,isEmptyAddress,isEmptyWhateverWhen the validator object could be computed in one place and passed around during the program lifecycle. Let’s say:
Validator v = Validator.getInstance( ... );and then use it as :validator.isEmpty()and let polymorphism to it’s job.Alternatively you could pack the arguments in one class and pass it to the
isEmptymethod, although you’ll end up with pretty much the same problem of the name. Still it’s easier to refactor from there and have the new class doing the validation for you.