ITrackStatus is implemented by quite a few classes in the framework. The fact that for the lowest level object that contains primitive field values there's no difference between IsDirty and IsSelfDirty doesn't mean that the difference doesn't exist for other classes.
If the FieldData implementation threw exceptions that'd break parts of the framework that require the interface actually be implemented.
Ok, I afraid I am still not getting it!! Looking at the IsSelfValid and IsValid implementation I see the following:
bool ITrackStatus.IsSelfValid
{
get { return IsValid; }
}
bool ITrackStatus.IsValid
{
get { return IsValid; }
}
protected virtual bool IsValid
{
get
{
ITrackStatus child = _data as ITrackStatus;
if (child != null)
{
return child.IsValid;
}
else
{
return true;
}
}
}
What I was expecting to see was something like:
bool ITrackStatus.IsSelfValid
{
get
{
ITrackStatus child = _data as ITrackStatus;
if (child != null)
{
return child.IsSelfValid;
}
else
{
return true;
}
}
}
bool ITrackStatus.IsValid
{
get
{
ITrackStatus child = _data as ITrackStatus;
if (child != null)
{
return child.IsValid;
}
else
{
return true;
}
}
}
So basically the IsSelfValid calls its IsSelfValid counterpart and the IsValid calls its IsValid counterpart.
Is there a problem with implementing IsSelfValid and IsValid the way is listed in the scond example?
Thank you.
There are no problems with the current implementation. I was simply curious of why IsSelfValid and IsValid are both implemented the same way.
As far as I can see, at the end *both* properties (IsSelfValid and IsValid) call the ITrackStatus .IsValid method when the object implement ITrackStatus.
I was expecting that IsSelfValid would call ITrackStatus.IsSelfValid and that IsValid would call ITrackStatus.IsValid.
So let’s just pretend for now that *all* objects used in a CSLA implemented the ITrackStatus interface.
Why can’t the implementation of IsSelfValid and IsValid be something like:
bool ITrackStatus.IsSelfValid
{
// This:
get { return ((ITrackStatus)_data).IsSelfValid; }
// Not this:
// get { return ((ITrackStatus)_data).IsValid ; }
}
bool ITrackStatus.IsValid
{
get { return ((ITrackStatus)_data).IsValid ; }
}
Ahh, in that case I'll quote various Microsoft people I know: "Because shipping is a feature"
While I try to make the code as neat and clean and nice and perfect as possible, I don't have infinite time. (sadly my time is extremely finite) Since I want to keep up with Microsoft and do cool/fun stuff, I don't always take the time to go back and perfect code once it is working.
In fact, a lot of my code cleanup typically occurs when I write the big books, because that writing process forces me to go through much of the code in detail so I can explain it - and it is easier to explain tight, clean code. As the framework has grown though, the percentage of the framework code that is in the book has shrunk. It is either that or the book would become rather huge :)
Copyright (c) Marimer LLC