Everything seems cool to me except the name of the function "HasMax10Chars".
What if tomorrow the maximum length turns 11?
Shouldn't it better to have a function called like "HasValidLength" or something similar?
Hi Roy,
I have run into a whole lot of problems with Validate functions that returns a boolean in the past. They are not flexible enough. I have adopted creating the validation rules into a IRULE interface. The actual validation can actually be done by a delegate that is a property of the IRULE. So now the Validate function can return a List which will facilitate more meaning error messages etc.
Thank You,
Vish
Vish: you're assuming all "rules" have the same inputs, which might not be the case. they might also have different outputs. How would you hand;e that?
Jan Van Ryswyck:
in essence, my implementation is that of a hard coded specification. just change the name of "Validate" to "IsSatisfiedBy" and think of each of the protected methods as leaf specifications.
the Validate method is a composite hard coded specification. the problem is still - how to you test (or rather TDD) that the correct composite specification is being built? so I want my test to fail if my IsSatisfiedBy method isn't using the leaf specifications as it should (which means it's logic is flawed).
Diego: yeah, the name might be a bit too much but that's what refactoring tools are for.. :)
Diego: yeah, the name might be a bit too much but that's what refactoring tools are for.. :)
Hi Roy,
Using generic delegates gets you half the way there
And using a delegate definition like
delegate void CustomValidate1(T value, List others);
delegate void CustomValidate2(T value, List others);
might help you out further. But yes they are hacks but i found them to be better.
And the output of rules are almost always messages that can be made a property of the rule itself or a new type for validation results can be created and a list of the broken rules or the validation result type can be returned by the validate function.
Thank You,
Vish
Hi - I must confess I am not a TDD expert, but seeing this video really had me raise my eyebrows.
The scenario is that you are developing a framework, that should be used within your company. you want to TDD the framework (which i believe is a good thing!). then you start using different patterns that allow for the framework to be testable (good), but meanwhile you make consessions with regards to your public API (bad).
I could easily see myself in a situation in which I would have to explain... yes, well... the Fx design is kinda awkward. but this was just the easiest way to test the Fx.