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

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.

    • Replies are listed 'Best First'.
    Re^18: Assignable Subroutines
    by Aristotle (Chancellor) on Jan 27, 2005 at 17:19 UTC

      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.

    		[reply]

        For "zip code" do you mean US zipcodes? UK postcodes? Any of them? All of them?

        I think if there is a "standard zipcode" definition within your company/project/application, then those for attributes are related, and it would make sense to create an separate class for dealing with them. But I would assume such a class to have considerably more functionality that just validation.

        If the only constraint on those disparate fields is that they must be positive integers (what size?), then you can probably get away with making them a type.

        However, if we are talking about 4 truely disparate and unrelated attributes of 4 truely unrelated classes, that just happen to require a similar type of validation--at the moment--then it would be downright dangerous to use a common routine for performing that vaidation. As soon as one of them changes, the nature of their unrelatedness is likely to cause the the maintenance programmer to modify the validation routine commesurate with the one that changed and be completely oblivious to the other three which haven't.

        Finally, if there are sound reasons for using a single vaidation routine for the 4 disparate attributes, I would just call that routine within the second code block of the LVALUE keyword I described. It in no way precludes that.

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

          You can get away with a type for the positive integers even if their ranges differ: it's a parametrizable type.

          the nature of their unrelatedness is likely to cause the the maintenance programmer to modify the validation routine

          That's just silly and backwards; the kind of tunnel vision resulting from your insistence on validating inside the accessor. If I want to store strings in a property formerly declared as an integer, I'll change the type declaration for the property, not the definition of an integer.

          Makeshifts last the longest.

    		[reply]

    In Section Meditations