#2 rework constraint implementation slightly
Very cool project. Haven't gone through code yet, but
the tutorials display the beginnings of an interesting
approach! Would be interested to know which sources
have influenced your implementation?
objectarchitects.de? Ambler's approach? Homegrown?
I was reading through the constraints tutorial and
noticed that you return an SpfBrokenConstraint instance
when a constraint is violated and null otherwise. The
null tickled my mind about using a null object pattern
and then having a ConstraintManager class whose
responsibility it was to deal with the outcome of the
constraint. Just to eliminate the obvious conditional
that arises testing for null vs. a returned
SpfBrokenConstraint. But I think that alone might not
be a good justification.
Then, however, it occurred to me that you might get
some real mileage out of changing this so there is a
parent class/interface, e.g. "ISpfConstraintResult" or
something, then derive SpfBrokenConstraint and
something like "SpfHeldConstraint" (or some better
name) from ISpfConstraintResult. Your delegate could
then return an ISpfConstraintResult and leave to a
higher power the outcome. For example, you could
make available a utility ConstraintManager class that
centralized business rule handling, and also (here's the
key!!) capability to operate in verbose mode. In verbose
mode, the ConstraintManager could query
SpfHeldConstraint (and SpfBrokenConstraint as well, I
suppose) for information on which constraint was
successfully passed. The ConstraintManager could
then log this info or make it available for logging. Might
be a real plus (I think) when trying to debug business
rule implementations. Especially in more complex
scenarios of composite objects.
Just a thought -- I'm sure you have plenty of other tasks,
but the above capability would be a really nice feature.
Kindest regards,
Simon Taylor
