Method Name Suggestion: Validate a Poor Choice?

[Mike Hofer]

I like it. It's better. What about Parameter instead of ParamRule?

Oh, and Parameter it is.

 

[Mike Hofer]

Oh, and Parameter it is. - Hide quoted text -

- Show quoted text -

Okay, I did a lot of testing in the code base today, and I'm having
some difficulty with the end results of the tests. The end results of
the test code in NUnit seem to be defeating one of the key tenets of
the design ("Less code, not more"). For example:

[Test]public void ThatPasses()
{
Validate.That(m_arrayOfIntegers, "m_arrayOfIntegers").IsNotNull();
Parameter.Check.That(m_arrayOfIntegers,
"m_arrayOfIntegers").IsNotNull();
}

It's also presenting another design problem from the point of view
that the Parameter class itself has one member: the Check property,
which returns a reference to the class factory. That's its sole reason
for existence. I'm having a hard time justifying that.

So, I'm back to the drawing board. I'm pretty sure I'm going to drop
the container class. On the other hand, I'm sticking with Demand in
lieu of Validate. I actually considered Check, and tested it. But
Check doesn't carry the same weight that Demand does; Demand carries a
psychological weight to it that I think is better suited to what I'm
trying to do.

So, no wrapper class, but I will change it from Validate to Demand.

Demand.That(foo, "foo").IsNotNull().StartsWith("bar").EndsWith("baz");

Unless anyone else can think of something really stunning, thanks for
all your input and help. It's meant an awful lot to me.

 

[Paul E Collins]

I agree and I believe it's better OO to do so. Classes get noun
names, methods get verb names, properties get adjective names, [...]

I think property names are more frequently nouns (e.g. height, colour,
index).

Eq.

 

[Ngan Pham]

Anyone please tell me where to download NValidate?.

 

[Juan T. Llibre]

It's not available yet.

Look for the release announcement at :

http://www.nvalidate.org/

 

[Mike Hofer]

Anyone please tell me where to download NValidate?.



















- Show quoted text -

The Alpha Release of NValidate will be uploaded tonight. THIS WILL NOT
BE PRODUCTION READY CODE. It's being released for public review.
However, since it's being released under the GPL, you're free to fix
any bugs you find and run with it.

Just don't expect to be able to sue me if it blows your foot off.

The web site's been expanded to include the API reference and
community forums. You can find them at http://www.nvalidate.org. Note
that the docs have some holes in them; they'll be fixed tonight as
well. (I'm posting this from work.)

Thank you for your interest!!

 

[Brian Gideon]

The Alpha Release of NValidate will be uploaded tonight. THIS WILL NOT
BE PRODUCTION READY CODE. It's being released for public review.
However, since it's being released under the GPL, you're free to fix
any bugs you find and run with it.

Just don't expect to be able to sue me if it blows your foot off.

The web site's been expanded to include the API reference and
community forums. You can find them athttp://www.nvalidate.org. Note
that the docs have some holes in them; they'll be fixed tonight as
well. (I'm posting this from work.)

Thank you for your interest!!

Mike,

I downloaded it and gave it a brief test drive. The API is pretty
much how I envisioned it would be. I really like how similar the
"feel" is to NUnit's API. I think Demand is a great name for the
factory class and I'm actually glad that you decided against having
that ParamRule static class as portal to get to Demand.

You know...it's use cases might not just be limited to parameter
validation. I'm thinking that it could be a complelling solution for
a lot of different things including Debug.Assert, user input
validation, etc. I'm not sure how narrow of a scope you want to keep
for the project though.

Brian

 

[Brian Gideon]

The Alpha Release of NValidate will be uploaded tonight. THIS WILL NOT
BE PRODUCTION READY CODE. It's being released for public review.
However, since it's being released under the GPL, you're free to fix
any bugs you find and run with it.

Just don't expect to be able to sue me if it blows your foot off.

The web site's been expanded to include the API reference and
community forums. You can find them athttp://www.nvalidate.org. Note
that the docs have some holes in them; they'll be fixed tonight as
well. (I'm posting this from work.)

Thank you for your interest!!

Mike,

I downloaded it and gave it a brief test drive. The API is pretty
much how I envisioned it would be. I really like how similar the
"feel" is to NUnit's API. I think Demand is a great name for the
factory class and I'm actually glad that you decided against having
that ParamRule static class as portal to get to Demand.

You know...it's use cases might not just be limited to parameter
validation. I'm thinking that it could be a complelling solution for
a lot of different things including Debug.Assert, user input
validation, etc. I'm not sure how narrow of a scope you want to keep
for the project though.

Brian

 

[Mike]

Mike,

I downloaded it and gave it a brief test drive. The API is pretty
much how I envisioned it would be. I really like how similar the
"feel" is to NUnit's API. I think Demand is a great name for the
factory class and I'm actually glad that you decided against having
that ParamRule static class as portal to get to Demand.

You know...it's use cases might not just be limited to parameter
validation. I'm thinking that it could be a complelling solution for
a lot of different things including Debug.Assert, user input
validation, etc. I'm not sure how narrow of a scope you want to keep
for the project though.

Brian

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.

 

[Brian Gideon]

I was hoping you might
offer your opinion on that, now that you've had an opportunity to look at
it.

I'm taking a short vacation this weekend so I'll follow up with a post
in a couple of days when I get more time.

 

[Brian Gideon]

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:

I couldn't agree more.

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.

Typically you would only do parameter validation on public methods
anyway so it's not like people are going to be littering their code
with calls to NValidate to begin with. Furthermore, based on what you
just said, there's only one object per parameter. So I agree that
object creation would be small relative to the rest of the developers
application. The actual tests would have to be performed regardless
of whether someone is using NValidate or doing it manually so I don't
see any extra work going on there except for maybe the overhead of
calling the different methods which might actually be inlined in
several (most?) of the cases.

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.

Like you said, do some testing. My hunch is that it won't be that big
of an issue. Even if it is I'm sure there are more things that could
be done without redesigning the API.

 

[Brian Gideon]

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:

I couldn't agree more.

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.

Typically you would only do parameter validation on public methods
anyway so it's not like people are going to be littering their code
with calls to NValidate to begin with. Furthermore, based on what you
just said, there's only one object per parameter. So I agree that
object creation would be small relative to the rest of the developers
application. The actual tests would have to be performed regardless
of whether someone is using NValidate or doing it manually so I don't
see any extra work going on there except for maybe the overhead of
calling the different methods which might actually be inlined in
several (most?) of the cases.

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.

Like you said, do some testing. My hunch is that it won't be that big
of an issue. Even if it is I'm sure there are more things that could
be done without redesigning the API.