Refactoring the .Net Framework

By: David Starr Category:General PostTag: .Net, New Post:

What possible reason could there be for sealing the System.IO.File class? A sealed class means I must wrap the class just to have my own functionality, rather than extending it. Further, it becomes significantly painful to mock the class in unit tests without an interface.

Granted, Microsoft is doing mucho better these days, and I doubt this decision would be made today if they were re-releasing the framework. So why not go in there and unseal things like this as a service pack? Look at what the ASP.Net team has done for IHttpContext as an example. Good stuff.

I know I am not the first or last person to rant about these things, but here’s my question. Why can’t these refactorings be released into subsequent versions of the framework?

The “Extract Interface” refactoring is a pretty easy one.

5 thoughts on “Refactoring the .Net Framework”

Hey Dave. I thought the IHttpContext the Asp.Net/MVC team was working with got moved to an abstract class HttpContextBase ~

http://haacked.com/archive/2008/02/21/versioning-issues-with-abstract-base-classes-and-interfaces.aspx

The one linked looks like its from IIS 7, is that right? Hmm.. confusing.

As for the sealed classes, you could always use Extension Methods. Though im sure you know that, and its not the point of the post…

Hi David,

Often times the decision to seal a class is made with security or performance considerations in mind. The IHttpContext refactoring was probably not one of those and was just one that they got wrong. However, I could see some security challenges with unsealing classes like String or File.

http://codebetter.com/blogs/patricksmacchia/archive/2008/01/05/rambling-on-the-sealed-keyword.aspx

Here’s an even more verbose discussion on it.
http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=411

One thing that recurs in the discussion is the idea that sealing within a framework product implies a lack of functionality in using the framework.

I may have to think on this one a bit more.

Just a thought as to why it hasn’t been changed … It can’t be “easily” changed in a service pack.

System.IO.File is a class that is covered by the ECMA specification for the BCL. There aren’t a ton of classes in the spec but it is one of them. A change to it would require an update to the spec which is not a trivial manner (I can only imagine the red tape surrounding that one).

Cheers,

Greg