Consider the following (bad) code:
class Program
{
static void Main(string[] args)
{
new SubClass("go");
}
}
public abstract class BaseClass
{
protected BaseClass()
{
this.Run();
}
protected abstract void Run();
}
public class SubClass
: BaseClass
{
private string data;
public SubClass(string data)
: base()
{
this.data = data;
}
protected override void Run()
{
Console.Out.WriteLine(data.Length);
}
}
The issue of calling virtual members in constructor has been discussed in depth before, so I won't cover it here (see http://blogs.msdn.com/b/scottwil/archive/2005/01/14/353177.aspx and http://msdn.microsoft.com/en-us/library/ms229060.aspx for details). It's not that you can't do it right, but it can cause issues if you're not a little careful. This issue actually bit me years ago because I'm fond of designs where my base class tells the subclasses to do something when the constructor is called. However, it's too error-prone - all it takes is for someone to subclass my class that's a little careless and then all sorts of bad things happen.
A while ago I ran into Pex (http://research.microsoft.com/en-us/projects/pex/), and I fell in love with its power and capabilities. It was kind of freaky-scary what Pex would uncover in my code - suddenly there were corner cases with a bright shining light on them and I realized that I have subtle errors that I really should fix! Pex is also interesting because of the technologies and frameworks that it uses that do all sorts of advanced, cool stuff. One in particular is called ExtendedReflection. This is basically a managed profiler - yes, you read that right. For the longest time I was under the impression that you can't write a profiler in .NET in managed code, but I was wrong, because ExtendedReflection does just that.
So what does this have to do with calling virtual members in constructors? Think of flipping around IDisposable. See, IDisposable works with the using statement in C# to automatically call the Dispose() method. Of course, this is all compiler magic; the runtime doesn't treat IDisposable-based objects any differently, so if you forget to call Dispose() in a timely manner, you could leak resources (depending on what the object used during its lifetime). Now, you could argue that the runtime should handle this for you, but that's not an easy problem to solve - in fact, it's downright difficult. But ... wouldn't it be interesting if you could have the runtime call a method on your object if it implemented a specific interface after the constructor was done but before anything else was done to the object?
Read more: Jasonbock.net
QR: 
Posts
0 comments:
Post a Comment