On Oct 11, 3:31 pm, "Nicholas Paldino [.NET/C# MVP]"
<m...@spam.guard.caspershouse.com> wrote:

I'm thinking about this suggestion, because it has merit. But I'm
wondering if this isn't possible just using namespace resolution.

Thoughts?

Demand (formerly Validate) is a class factory; it's a singleton, and
so each of its methods simply returns a different validator class
based on the argument list. Like so (watch out, real NValidate code
coming!):

using System;

namespace NValidate.Framework
{
 public sealed class Demand
 {
   public static ArrayValidator That(Array parameterValue, String
parameterName)
   {
     return new ArrayValidator(parameterValue, parameterName);
   }
   public static BooleanValidator That(Boolean parameterValue, String
parameterName)
   {
     return new BooleanValidator(parameterValue, parameterName);
   }
   public static ByteValidator That(Byte parameterValue, String
parameterName)
   {
     return new ByteValidator(parameterValue, parameterName);
   }
 }
}

(Obviously, we're not dealing with rocket science, here. =D)

Given that it's purely a class factory, and the XML documentation
comments (which I snipped for brevity) make that pretty clear, my
reservations about it having only one distinct method with multiple
overloads are not substantial enough to warrant a complete rewrite at
this time.

Now, having said that, if someone can provide a better solution that
will be more extensible (I'd *really* like for developers to be able
to dynamically invoke their own validators at some point), I'm all
ears. The class factory design you see above is pretty restrictive;
it'll work for the first iteration, and it's extensible from the point
of view that users will have the source code and can extend the
library themselves. BUT...

What would be nice is if a 3rd party DLL could create a class that
implemented an interface or extended a base class or something and
passed that to NValidate for invocation. That would allow end-users to
write more complex test sets, and possibly more efficiently than
NValidate can execute them individually. I've figured out the idea
behind a basic interface or a function pointer approach, but the
problem arises where users want to pass *more* information to the
custom validator. I could use some help figuring out how to do that.

Oh, and Parameter it is. :)

Thanks VERY much for downloading and test-driving the framework.

My goal in writing NValidate is to make it easier to write higher quality
software by writing less code without sacrificing clarity or significantly
impacting performance. (I would venture to say that that statement, in a
nutshell, summarizes the purpose of NValidate.)

If extending it to support additional validation outside of method and
property validation satisfies that rule, I'm game. But the scope of the
product must be reasonably constrained. There's another additional rule: The
end users should never be asked to use something that's so complex that they
can't reasonably explain it. If *we* can't explain what it's doing or how it
works, forget it. In my book, that's an unsafe operation. :)

Regarding the dropping of the ParamRule "domain": I'm very pleased that it
was dropped. It seemed unnecessary, and I simply couldn't justify it. It was
an entire class with one property on it:

public sealed class ParamRule
{
  public Demand Demand {
     get { return Demand; }
  }
  private ParamRule()
  {
  }
}

It seemed rather idiotic to me. Further, if you were going to do something
like that, you might as well have named it "I", and change Demand to Insist:

  I.Insist.That(dateOfBirth, "dateOfBirth").IsNotInFuture();

Now that's a truly fluent interface, but it's approaching the absurd, just
to satisfy OO purists. In the end, I decided to leave it out, and save the
overhead. I'm really happy with the way the API flows now, and aside from a
few known issues that I've got slated for resolution, I'm confident that
it's going to be a pretty decent product once it's finished.

I do have one concerned raised by a member on the NValidate forums. He's
concerned that creating lots of objects just to validate parameters might
negatively impact the application's performance. I was hoping you might
offer your opinion on that, now that you've had an opportunity to look at
it.

Before you do though, I'd like to offer the following points:

1. I specifically split the validators into two groups, derived from two
different base classes so that boxing and unboxing would not occur when the
value of a value type parameter was cached within the validator itself.
2. Only one validator is created per parameter. If the caller chains the
tests together (as intended), the same validator is reused over and over
again.
3. Each validator only holds two pieces of information: the name of the
parameter (a string), and the value of the parameter. So we're not keeping
lots of data in memory.
4. The validator's test method must conduct its test and either throw an
exception if the test fails or return a reference to the validator. The
tests are written to be as fast as possible. (If they're not written that
way, that's a defect and needs to be resolved.)
5. I avoided reflection and attribute-driven solutions because they tend to
be slower. (Reflection requires loading and parsing an assembly's manifest;
attribute-driven solutions require reflection.) The sole case where I use
reflection is in the IsValid test on the EnumValidator.

So those are the performance-measures I took when designing the framework. I
realize that we're going to have to just test the thing and measure the
impact and provide raw numbers at some point. But my gut feeling is that the
number and complexity of the objects were creating is so small compared to
the number and complexity of other objects created throughout the lifetime
of an application (or even within a method) that the impact will be minimal.
Again, I fully agree that testing must be done to prove this and fix it if
it's not true.

I do have a solution in mind if we think this will be a serious problem. I'd
just like to get a feel for whether or not it's worth redesigning the
framework or not.