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.