Partial Classes Are a Framework Feature
Like it or not, Visual Studio .NET generates some code on your behalf and there's no known way to stop this procedure. If you don't want tool-generated code dirtying your files, you have no other choice than to manually delete and replace it with your own similar code. With the traditional class compile model, Visual Studio .NET can only edit the source code within the class. It created a common InitializeComponent
block, wrapped by a region and hidden from view. Any change to the programming interface of the class results in a change to this piece of code. Sure it works, but it's probably not the model you want to hand down to posterity.
When working with tool-generated source, made-to-measure code can be added to the class without having to edit existing sections or recreating the file. Many classes in Visual Studio are partial classes that developers can extend by creating an additional file. In Windows Forms, Visual Studio .NET 2005 stores designer code to a separate file, say, the form1.designer.cs file, that is hidden from view by default (see Figure 2
|Figure 2. Form File Class Association: A form file is associated with an XXX.designer.cs class file.|
The "About" form of the application in the figure is associated with a designer file. That file contains the source code in charge of the creation and positioning of the various controls. The huge difference with previous versions of Visual Studio .NET is that now you have this code insulated in a specific project file.
So far, it may seem that partial classes are an exclusive feature of Visual Studio .NET created to solve some of the past issues that some .NET 2.0 compilers supported. There's more than this, of course.
The key thing going on is that partial classes are a full .NET Framework feature. Partial classes are first-class citizens in the post-Whidbey era and should be part of any .NET developer's toolbox. Let's see why.
When working on large projects, or when working on a very complex component, spreading a class over separate files has a number of benefits. First off, it allows multiple developers and/or teams to work on it simultaneously. Members of the development team can work on different files with no need to keep anything in sync. When everybody is done, the compiler finalizes the job. It's simple, effective, neat, and elegant.
In Figure 2, you also see that a pretty complex form, the form named TocEditorMainForm, is composed of several constituent files. In the end, a form is a class and to spread its code over multiple files, you normally need to design it very carefully so that each file implements an independent "subclass" with some points of contact with the main one. Allow any of the methods on the "subclass" to access a member on the main form by passing a reference to the main form.
Note that I used quotes to wrap the word subclass just to assign it a special meaning. Subclass here doesn't hint at some hierarchical relationship existing between classes. The form and the "subclass" are both at the same logical level. I used the term "subclass" to indicate that the "subclass" specializes and fleshes out the body of the main form class adding some ad hoc functionality.
The mechanism of partial classes lends itself very well to completing classes with additional features without resorting to sophisticated design patterns. For example, if your class implements multiple interfaces, it is generally a good idea to create multiple partial classes to contain the implementation for each interface.