Suddenly liking partial classes…at least for refactoring

I don’t consider myself the most elite of programmers, or even a great one (as yet), but I do know some basics about programming theory. So when I was thrown into this Microsoft world of ASP.NET and C# alot of new ideas were tossed my way which I had (and still have) problems accepting as convenient without sacrificing “good programming practice.” One of these is ASP.NET 2.0’s Partial Classes feature…or at least was until today.

Basically with partial classes you’re allowed to separate a class into multiple files by declaring them as “partial”, each individual partial class is supposed to contain some piece of individual logic. The thinking was that if you bunch all the pieces of logic together into one class file they’d get lost and make debugging a tonne harder. My thinking at the time this feature was revealed to me was that code should not be so coupled that classes get so big that you would need this sort of feature.

However when you hit Enterprise level applications the thinking does change a bit. You learn quite logically that enterprise level code requires variance in these “rules” just because of the complexity of such systems, or the load these applications would be expected to handle speedily.

My take on partial classes was still neutral, until about 15 minutes ago, when a change request came in from my CEO (strangely enough, not the one I had initially asked for, what a wonderful thing refactoring is :-) )

A class currently written and implemented was determined to be unnecessary, and was to be contained within another class altogether…

“ARRGH!!” I screamed silently, “Do you know how long it will take me to cut and paste all the code into nice isolated portions in that other class and make sure the reference calls are updated so everything doesn’t break???”

Well, thankfully my quiet mind kicked in about 5 minutes and a short reflective walk later, and as I looked at the problem, I realised this was a perfect case for a partial class. I didn’t want this piece of programming logic mixed up with the other, I mean, the point was true that they belonged to the same object type, but they were put into these separate classes initially because of the varying method requests each object instance would need.

In the .NET world, unlike Java, the class declared within a file doesn’t have to be the same as the physical filename itself. Hence by using partial classes, the physical file name of each C# source file would supply the description of what “part” of this object’s logic was declared within this file. In my case, I had one object, let’s call it Item, where it just contained one set of properties for processing, and another object which contained a collection (multiple) of items, let’s call that ItemCollection, each with its own set of properties for processing, and which led it onto a slightly varied processing path before each Item it contained was processed because of these unique properties of the collection.

By separating the logic into two physical files (Item.cs and ItemCollection.cs) and declaring each as a partial class of the same class name (Item), I acheived my goal of separating the logic path each object instance takes, while also acheiving the request goal of tying together the different physically stored files under the umbrella of one declared class (and hence one instantiated object when its constructor was called). Yay for partial classes, you saved me today from a whole heck of work if I was doing this in PHP/MySQL :)

Leave a reply