in reply to Re^14: Assignable Subroutines
in thread Assignable Subroutines

And you would trade all that for the simplicity of the commented out code?

I rest my case!


Examine what is said, not who speaks.
Silence betokens consent.
Love the truth but pardon error.

Replies are listed 'Best First'.
Re^16: Assignable Subroutines
by Aristotle (Chancellor) on Jan 27, 2005 at 03:12 UTC

    Please show how you would propose to validate values for four attributes, each in a different class, but validated in the same way, using some approach that assumes something like the commented out code worked.

    Makeshifts last the longest.

      It would depend upon 2 things:

    • How complex is the validation criteria
    • What, if any relationship is there between the four classes/attributes

      Perhaps the best test of the relationship is:

    • If the validation criteria changes for one of the attributes, will it change for all of them? Always?

      If the answer to that question is yes, which implies that the four attributes represent the same entity in the four classes, then it wold make sense to factor that code into a common place.

      Maybe as a utility subroutine called from the inline validation code. But then again, if they are all the same thing, maybe they should be a separate class? That would I guess depend upon whether they have any other behaviours besides existing and requiring validation.

      However, if these are completely unrelated fields that just happen to require similar validation criteria--as, perhaps, required to be lower case--then I would not use a common validation routine.

      To do so leaves you open to someone changing the validation routine to accomodate future changes in one field and unwittingly breaking the other three unrelated classes.

      In either case, whether done manually, or through a subroutine, the best place for it is right there after the value is assigned.


      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.

        Say all of those properties store zip codes. Or they must be positive integers. Or they must contain an absolute path to an existing file. The classes are completely unrelated.

        You'd write the validation code over and over for those? Doesn't it make more sense to be able to declare "this property stores a zip code" and be done with it? Isn't it desirable that an improvement to the zip code validation class would trickle through to all four instances?

        Makeshifts last the longest.