People who ask questions like that are good arguments for eugenics. There. I said it. If you call into question the short-term survivability of a platform as vibrant as either .Net or Java, you should be sterilized. As should all of your offspring.
...possibly anyone who didn't slap you when you initially asked the question.
Okay. That's out of my system. Pending a disclaimer, let's ask some real questions.
DISCLAIMER: I am not an authority on Microsoft's motives. I am not an authority on anything, for that matter.
Question #1: A common pattern, in today's world, is to program to an interface and use an abstract factory, service locator, etc. to obtain instances thereof. How come most of the .Net framework does not use this pattern?
Answer #1: You won't like the answer.
Question #2: No, seriously, tell me!
Answer #2: Because you make them cry. People, generally, don't understand things. For instance: beyond the basics, I don't know how a car or a lung works. The world is big and scary. It is filled with monsters, wars, tragic deaths, and scary spiders. These and a myriad other things all drive the average person - including the average programmer - to simply "tune out." Having to explicitly use an abstract factory or other "servicey-locatory-type-thingy" is an extra step that half the people just won't comprehend and the other half will question the validity of. Using new, on the other hand is comfortable; It's easy to read and understand.
Fortunately for everyone, those tricksy hobbitses at Microsoft figured out a way to build a "servicey-locatory-type-thingy" directly into the .Net platform: binding redirection. Through this artifice Microsoft can update a .Net framework assembly without disrupting dependent assemblies. That's right: Because of binding redirection, you can sit on your couch, drink your pepsi cola all evening, leave the reality TV shows running while you sleep, then drive your SUV to work and keep using new without having to worry if Microsoft is going to update an assembly on you.
The bottom line is this: They did implement a dependency inversion mechanism it's just too transparent for most people to see and they did it that way because they don't trust you. I don't trust you either but that's probably not your fault: I know the coffee machine lies but it's words are like honey... I just get all mixed up.
Question #3: Should I just use binding redirection?
Answer #3: If you have to ask, the answer is probably "no." There are reasons to use it and reasons not to use it. Let's go over them together as two friends holding hands:
Good points:
- You can apply it to applications you have already deployed
- It allows for intuitive construction of objects using new
- It requires no maintenance
Bad point:
There is really only one bad point. Reliance on binding redirection as one's primary mechanism for dependency inversion hides certain design problems until after the fact. If you have to conform to a service location mechanism, you are more likely to think about where boundaries between services and consumers might be. Likewise: you are more likely to use interfaces to address a class hierarchy than actual implementations.
The System.IO namespace is a good example of the downfall of reliance on binding redirection. All streams must derive from System.IO.Stream, which is monolithic and does not capture the essence of "streamness." Instead, because .Net's linear inheritence is so limiting, it attempts to provide hooks for all features that a stream might offer. If you need a concrete example, take CanTimeout, ReadTimeout, and WriteTimeout. In a proper, interface-driven, class system, one might break these out into a seperate interface (one that implemented IStream); it is likely that CanTimeout would retire altogether.
Again, this is not a failing of binding redirection, it is a failing of the class-system designer. Binding redirection is just an accessory.
I tend not to use binding redirection and, when I'm helping an organization set its infrastructure up, I recommend against it. A custom solution is easy to implement (more on that later... I'm tired), easy to maintain, and begs certain questions that historically people do not ask.
