partial class has its source code split over multiple source files, each of which appears to contain an ordinary class definition from beginning to end. Ideal for team development, partial classes simplify coding and avoid manual file synchronization in all those situations in which a mix of user-defined and tool-generated code is used, like Visual Studio .NET projects and ASP.NET pages.
Until I got a copy of Jeff Prosise's book on MFC
, I thought that Windows programming with MFC was only possible through wizards. In his book, Jeff showed me the way by creating a small but working MFC application without Visual Studio and its rich suite of wizards. Likewise, until I saw partial classes in action in Beta 1 of Whidbey, I thought that Windows Forms programming was only possible through wizard-like, and, frankly, bothersome, tool-generated code.
Technically speaking, a partial class is a class whose definition spreads over multiple and distinct source files. In real-world programming, there are several situations where splitting the definition of a class is desirable. By declaring a class partial, you state that source files can be added to the same project to extend the functionality of the class.
No hidden object-oriented principles lay behind partial classesjust the made-to-measure compiler's ability to build and process a class definition from various sources. Partial classes are a source-level, assembly-limited, non-object-oriented way to extend the behavior of a class.
In this article, I'll take a look at the motivation and definition of partial classes and the use you can make of them, especially in the context of Web applications.
Motivation for Partial Classes
If you have used Visual Studio .NET, you know about regions. A region is an IDE construct that expands and collapses blocks of source code. Regions were introduced with Visual Studio .NET and used mostly to hide tool-generated blocks of code. Tool-generated code is a characteristic inherited from Visual Basic 4. Remember FRM files?
You used to open FRM files in the IDE to see the graphical contentsbuttons, textboxes, and any variety of controls. In the end, an FRM file was nothing more than a text file filled with the declaration of visual objects: their sizes, locations, component names and versions, and current properties. In Visual Studio .NET, the declarative part of the form is available per view but hidden in a collapsed region. Why is this code tool-generated? Because developers never get to write it.
When you drop a control onto a form, some code needs be generated to track the name, size, and location of the selected control. The IDE or wizards writes this code for you. You don't need to interact with this code; you can move or delete controls through the visual interface and the designer. Whenever this happens, the hidden code is properly adapted.
As you can tell, the model is effective because it works, but it's very brittle too. Any changes made to the hidden code can potentially break the application or component. Any crash or anomaly in Visual Studio .NET potentially leaves the code in an inconsistent state.
A form class (both Windows and Web) consists of declaration code plus action code. The two are logically separated but can't just be placed in physically separated classes, no matter the relationship between them. Partial classes are a way to work around the issue. Logic and declaration go into distinct files but compilers have to be updated to be able to process a class from multiple source files.
By marking a class as partial, you enable the compiler to retrieve the whole set of members from various files, perhaps written at different times by different developers.