Code Duplication and others

Topics: Validation Application Block
Aug 7, 2007 at 12:12 AM
Wondering whether an emphasis is ever put on reducing code duplication... Here's some examples where it could've happened..

  • ValidationFactory. The if/else cache, cache lookup and lock is redundant.
    • By the way: this.ruleset == null ? other.ruleset == null : this.ruleset.Equals(other.ruleset). Ain't that what Object.Equals is for?
    • Could you have leveraged Caching AppBlock to implement the caches?

  • ValidatorWrapper and GenericValidatorWrapper: There is ONE line of code that differs.
    • By the way: InstrumentationValidatorDecorator or something similar would've documented way more what it's doing! Helper, Wrapper and Manager.... Not really meaningful to me...

  • Validator and GenericValidator
    • How about Validator : GenericValidator<Object> ? With some minor changes of course. We would have saved many LOC again.

  • OrCompositeValidator and AndCompositeValidator

Anyways, I could go on and on but I just think that when you show some sort of guidance, code duplication / reuse strategies and naming are as important as the blocks themselves.
Aug 7, 2007 at 12:48 AM
Hi Francois -

We did do a lot of refactoring throughout the development phase, but I'm not surprised there are some opportunities that we missed, as there's only ever a limited amount of time you can spend on such things.

One quick comment on the And versus Or composite validators - while they seem very similar at first glance, there are actually some pretty significant differences. The And validator simply runs all of its children one by one, and each child validator adds its ValidationResult to the collection if required. The Or validator needs to run its child validators, and then make its own decision on whether the result is valid. If not, it will create its own ValidationResult, that includes the children's ValidationResults as a nested objects.

Tom
Aug 7, 2007 at 4:10 AM
Given. And and Or composite validators have different validation strategies. My point was that by extracting the CompositeValidator base class, you could move up the internal Validator[] and potentially merge the Or and And data classes. I must admit I'm a bit freak with those refactorings. Next time, I'll post my comments while in beta... ;)