I recently received an email from a reader saying that while they liked my article, they really felt that I was off-track and that this blog entry was a better discussion of Partial Classes: http://www.theserverside.net/discussions/thread.tss?thread_id=34255

My article is from about a year ago and located here: http://www.windowsitpro.com/Windows/Article/ArticleID/43726/43726.html#feedbackAnchor

My article at least in my view makes pretty clear what Partial classes support.  First let me state my one concern with the new implementation of partial classes: 

The Partial keyword should be required in every source file of a partial class.

The reason for this has nothing to do with the compiler or pre-processing.  It has to do with developers and debugging.  When I open up a class I have no-way of knowing if it's a partial class, because out somewhere in the project another source file might exist which uses the partial keyword to extend that classes source code.  If the keyword were required I would immediately know that a second source file (which I could then find) existed.  Don't think this will happen... well here's an interesting scenario - if you convert a UI class from .NET 1.1 to .NET 2.0 it doesn't automatically move the generated sections of your source file into a separate source file to reflect the new paradigm.  So now you will have some classes where you will have one source file and others where you will have two source files - how will you know which are which since Visual Studio applies the partial keyword only in the generated and hidden source file?

Of course the question posed by the Server Side blog is would using generated virtual base class and virtual methods be better then just supporting the splitting of a class across multiple source files.  The answer here is an easy to see - No.  Why not?  Well lets start with the impact of the changes on the runtime environment and user.  Using a base class with virtual (overridable) methods means that you have impacted the runtime behavior of the application.  I'm not going to go into details but each overridable method and class in your hierarchy carries with it a minor performance cost.  Thus using a virtual class carries a runtime cost.

Aside from the disadvantages of the runtime cost of using an abstract class with virtual (overridable) methods what about at source time.  Well here again the answers favor using partial classes.  Using an abstract base class means that there will still be a second source file associated with the class.  Thus the Visual Studio behavior of separating/hiding the generated code would still work, unless you wanted to have a second set of generated code for your class.  Now you would be limited to either introducing another abstract base class into your hierarchy or leveraging one of the two physical files (either the generated abstract base class or your own custom class) to hold your other generated code.

Finally using partial classes in the source as opposed to having an abstract hierarchy allows developers the option of separating out complex logic which might need to co-exist within a single class into multiple smaller source files that can be manipulated independently.  This advantage isn't a reason for partial classes, but rather an interesting benefit of having them.