So I’ve done the math, if I do just one class a day I am going to be at this for decades given the size and scope of the .NET type-system. In fact its worse than that because between .NET 1.x and 2.0 the size of the out-of-the-box class library effectively doubled and if I included all thats coming in WinFX in my TODO list then I’ll never get done. The great thing about my original goal was that I wasn’t going to talk about every class on this blog.
Anyway – I did want to do a pretty quick post about the System.Activator class. The Activator class is one of those useful types which would be used in pretty much every enterprise scale .NET application around, both inside the Framework itself but also directly by developers like you and me. Its role in life is basically to support the instansiation of objects whether they be PONO (Plain Old .NET Objects), COM objects are even remote objects exposed by the .NET Remoting plumbing. To support that there are three main methods – CreateInstance(…), CreateComInstanceFrom(…) and GetObject(…), each with their own set of overloads.
Now – in .NET 2.0 there has been a couple of modifications (from a public API point of view) to the Activator class so that now there is actually a generic CreateInstance method. Now the curious thing is that this won’t necessarily help people who are using the CreateInstance method to do things like plug-in loading because you actually have to have the type information you are want to create an instance available at compile time. So effectively this:
SomeType instance = Activator.CreateInstance<SomeType>();
Is the same as this:
SomeType instance = new SomeType();
So you are probably asking the why question now right? A not-so-old wise man once said to me – “I don’t answer why questions”. Unfortunately I’m not going to take his advice and instead I’m going to try and speculate where this method might be useful – I’m thinking generic factory classes which attach background behaviours to the types they create. Here is a trivial example.
Now I don’t necessarily recommend spinning up a thread for every object you create in everyday code but I wanted to illustrate a concept. The use of anonymous methods was pretty cute though don’t you think?
P.S. I knew it – CreateProcess<T> is used inside System.ServiceModel in Indigo. I guessed, checked and was right. It just strikes me as the kind of place you would want to do the kind of interception that this little fella allows.