Last week I posted my first blog entry about a new feature in the C# language called anonymous methods. In this post I wanted to focus on another feature called partial classes. This time it is a feature that both C# and VB.NET support.
Like anonymous methods, partial classes are a compiler-based feature (meaning the runtime does'nt know anything about them). Another reason they are like anonymous methods is that they give us as developers more flexibility in the way that we write our code. Partial classes allow the contents of a class to be split across two class definitions, each with the same name. To enable this, the VB.NET and C# teams have each introduced a new keyword.
// A partial class implemented in C#.
public partial class SplitPersonality
{
}
' A partial class implemented in VB.NET.
Public Extends Class SplitPersonality
End Class
There are a few rules for the keyword usage that you need to be aware of, and they are a little bit different for each one, so let's look at C# first. The C# “partial” keyword must be applied to all classes participating in the partial relationship. All of the partial class declarations must also agree on the inheritance relationship, this can be done by explicitly defining the base class on each, or just on one and letting the compiler automatically determine it for the rest. In VB.NET the Extends keyword is only applied to each additional class declaration.
Now that I've covered off the syntax I wanted to take a moment to talk about the importance of this seemingly insignificant feature. The real benefit is not that you can split lumps of procedural code between class files but rather it opens up the compilers to exploitation by code generators working of more application specific syntaxes which are then transformed into VB.NET or C#. And the simplicity and reliability that entails.
To make my case I am calling two star witnesses, ASP.NET and XAML. ASP.NET already takes *.aspx and *.ascx files and transforms them into a target language, the server controls on server pages and user controls represent a declarative representation of the user interface. Developers, using code-behind (as one option) hook up procedural code to react to the user as they work with the page. This code and UI separation is achieved through a layer of inheritance where the code-behind file defines the base class which the page or control derives from when the declarative markup is transformed into the target language. This is a neat trick, but it a fairly complex way to achieve a merge of initial state and behavior.
With ASP.NET 2.0 you can now leverage a new feature called “code-beside”. Basically this is the ASP.NET team taking advantage of partial class support. The result is that the intermediate inheritance relationship is removed and things like member accessibility suddenly become along less complicated and tidier (they can be private instead of protected).
The Longhorn guys have taken a leaf out of the ASP.NET teams book with XAML as a markup language to create applications that live on top of Avalon (a new UI Framework shipping with Longhorn). XAML is an application of XML which allows you to declaratively define a user interface. XAML files are transformed into their target language just like ASP.NET, and just like ASP.NET you can place your procedural code in an accompanying source file that uses partial classes to get it all compiled into one.