Rather than writing an actual letter, which would do no good, I have chosen to write this post with the idea that as an MVP I should lead and teach by example. One of the most important design principles that factor into designing a framework is that of dependency hierarchies. In less fancy terms it simply means what classes implement what interfaces and where these things are maintained in the framework. Recently I placed a suggestion on Connect to Move INotifyCollectionChanged to System.dll so that more projects that do not require WindowsBase.dll (WPF) could use the functionality. Fortunately for .NET developers everywhere the suggestion was taken (although I won’t claim sole responsibility) and the move is happening.
This post is about the reasons for such a move, and such reasons are incredibly basic to realize. Consider a platform other than Windows whether it be Linux, Windows Mobile, the Xbox 360 or even the Zune HD. Now think about how you would write a framework that supports some of (or all) these platforms and consider the problem of developing a class that implements something like INotifyCollectionChanged. The problem, of course, is that not all the platforms have access to WindowsBase.dll. Thus the developers come to a crossroads: either recreate the functionality for the platforms or don’t implement the functionality.
While that may not seem too unreasonable a dilemma, the problem is that Microsoft implemented functionality in a branched assembly that really has no dependency on any classes or interfaces within that assembly. Here the principle is simple: when possible, move functionality up the assembly hierarchy so as to reduce cross dependencies. In layman’s terms, by moving the INotifyCollectionChanged interface to System.dll, many more projects can take advantage of it without requiring any sort of platform dependent code. And here it is important to remember that one of the original goals of .NET was to enable true cross platform development.
To say that this case is the only one of its kind would be ignorant. The scary thing is that I don’t think anyone actually has a list of where these mistakes exist and what can be done about them. Even scarier than that is the fact that Microsoft is making these mistakes. Consider the following which further demonstrates this point.
While helping someone today with a few questions on the System.Reflection namespace, a point was made about how odd it is to compare generic types. When you have a generic class such as Nullable<T> you cannot do something as simple as if(foo is Nullable) because the generic parameter can make a difference. While this isn’t too much of a problem, Microsoft later also developed the System.Data assembly and included an interface called INullable within this assembly under the System.Data.SqlTypes namespace. This, like INotifyCollectionChanged, constricts the use of this interface to only assemblies that reference System.Data.dll. Furthermore, the interface contains a single boolean property and has not a single dependency on anything within the System.data assembly.
The problem and its solution should be obvious: move INullable to the System namespace in System.dll and make Nullable<T> implement it. This allows developers to easily check whether or not a type represents a nullable type while not creating a single problem in the entire framework’s design. Furthermore it would allow developers to treat System.Nullable and System.Data.SqlTypes.* as the same types which can come in handy.
Update: I added a suggestion on Connect for moving INullable to System.dll.
Scott Hanselman has been on a roll lately with his posts and twits. Today he writes “Question to .NET Programmers: what is the difference between the System.* and Microsoft.* namespaces?”
This is an important question and one that I can’t say I truly know the answer too. I had always assumed it was based on either the idea that System.* was part of the core framework where as Microsoft.* was for Microsoft specific functionality. For instance, it would be expected that much or all of the System.* functionality would be replicated on many other platforms where as Microsoft.* would not.
Certainly this is true for the very basic feature set such as the common types but it is not true for System.Windows.Forms. Which begs the question that I always wondered: why is Windows.Forms where it is? I always expected it to be in Microsoft.Windows.Forms as it is a Windows specific implementation based on many of the Win32 controls.
With the arrival of .NET 3.5 and consequently WPF applications, Microsoft has done away with the old Application WinForms class. No longer can you call Application.LocalUserAppDataPath to get where the user’s files are stored. To restore this functionality as well as add a bit more, I have tapped into an uncommon resource: extension methods. Let’s dig a little deeper, shall we?