There is a pretty good article by Dino Esposito entitled “Implications and Repercussions of Partial Classes in the .NET Framework 2.0” that is in the latest issue of CODE magazine. Overall, Dino does a good job of introducing the reader to partial classes. I particularly like the section under the topic of “Usage of Partial Classes”, where he talks about splitting the CRUD functions and Business behaviors of a class into separate parts of the class definition. I particularly like this because I talked about it back here, and it shows that I’m not the only person in the world thinking that there could be some value in this. As a matter of fact, if you change the word “employee” for “customer” and “.vb” for “.cs”, the two discussions are really saying the same thing.
However, a few times in the article Dino makes the following statement about partial classes “partial classes are primarily a sophisticated form of text-merging and have nothing to do with inheritance and object-oriented programming” Which is 100% correct. Partial classes have nothing to do with inheritance or with OOP. As a matter of fact, they are completely agnostic to the concepts of OOP; not for it or against it. Partial classes don’t ask or answer any OOP questions. The whole story they tell is simply about allowing more then one source file to take part in a class definition. That’s it. Whether you use this to assist with code gen, splitting work responsibilities, layering, OOP, AOP, or whatever else you’d like to add here, it is totally based on how you use them.
For some reason, the fact that partial classes have nothing to do with OOP is often misinterpreted to mean that partial classes are against OOP. That somehow, partial classes by their very nature are anti-OOP. That is silly. Yet, a lot of partial class discussions often bring it up.
Dino, even prepares for this misconception by immediately following up his excellent point about using partial classes to introduce some layering concepts inside a class, by stating “If you're a design and OOP purist, you're already putting a curse on me. So, guess what? In this case, I wouldn't even suggest this to you.” IMO this is an unnecessary misconception. An OOP purist should not be concerned in the least with partial classes. They answer no questions for or against OOP. If somebody is trying to use partial classes to implement some OOP concepts then the fault lies with this person’s misconception of partial classes, not with partial classes.
Partial classes are about class file definitions; that’s it. Inherently (pun intended), they don't say anything good or bad about OOP. Partial classes could be used to create a 100% pure OOP solution or not, just like single code file class definitions can. There is nothing about partial classes that OOP purist should fear or scoff. In my mind they are purely a means for breaking the 1:1 coupling between a class definition and a single .vb or .cs file. OOP says nothing about .vb or .cs files so shouldn't be concerned with partial classes.
So, to go out on a limb and begin to change this misconception, I’m going to take a different stance. I’m going to say that if used smartly, partial classes can actually promote better OOP code. Yep, I’m not afraid of the OOP purist that will bark over this, because they wouldn’t really be OOP purist. They may be people on some other mission and soap box, but it certainly wouldn’t be OOP purism. In a previous blog, I talked about some of the reasons that we introduce layering into our code, and why layering in general can be a good thing. Well, in an attempt to promote better layering strategies developers very often do so at the cost of OOP principals. As a matter of fact, I would suggest that layering strategies (as important and good as they may be) often do more to break good OOP design then people like to admit. Actually, I would assume that “OOP Purist” would be more concerned about the damage done to OOP concepts by the current layering practices and trends then partial classes could dream of doing. For example, as soon as you introduce a data layer outside the scope of a class, based on the most common practices being done today, you are in OOP trouble. As soon as your data layer needs to know about the internal private data of a business object, you’ve parted ways to some degree with OOP. Likewise, as soon as you start assuming that a BO uses a traditional Data Layer as you would see in almost any MSDN article (i.e. separate assembly or at least a separate class), you usually end up talking about ways of getting data from the data layer into or onto the business object’s private variables. This usually involves some form of Data Transfer object, (or perhaps a handoff of a datareader from DAL to the BAL). Almost all of these solutions actually start leading you away from pure OOP.
If however, partial classes allow you to fully encapsulate an object’s behavior, including it’s persistence behavior (CRUD) within a single object, and yet still allow you to utilize some layering principals via separate code files, then in a sense partial class can promote better OOP. That’s right, they could provide a mechanism by which you are able to adhere to better OOP principals, and still gain the layering value of a separate code file; in this case, an object’s CRUD code can be maintained, supported, modified, etc. in a separate code file then the classes business behavior definition.
Hey, currently in .Net 1 you are able to create 1 .vb file with a ton of classes if you should like to do so. There may be (in your environment and development practices) some valid reasons this makes sense. I can’t think of any, but hey you could do this, and it really wouldn’t speak at all to your decision to follow OOP. On the other hand, partial classes allow you to separate a single class definition between multiple code files, and while this itself doesn’t really speak to anything OOP, it may allow you to make some purer OOP decisions and still gain some layering benefits that separate code files can provide.