Partial Classes [Q for DrPurdum]

Lodeclaw · March 13th, 2009, 01:11 PM

First of all I would like to say thank you, Dr Purdum, for writing this book. It has helped me tremendously! Have you written any other books on programming besides this one?

Now to my question:

I notice that in your book you write your solutions all into a single file as opposed to a partial class: a habit I've adopted myself. I enjoy having all of the code available to me on a single form.

Visual Studio, however, automatically builds windows forms as partial classes separating the automatically generated code from the user's code. I'm sure you're aware of this.

I was wondering what your thoughts on partial classes are. When would it be appropriate to build a form in a partial class and when would it be better to write it as a full(non-partial) class? I've read some of the benefits for using partial classes, but are there any down sides to this method?

Any information or insight you can provide would really be fantastic. Thanks for you time, Dr Purdum, and thanks again for writing this extremely helpful book!

-Joshua Siemens

DrPurdum · March 27th, 2009, 11:03 AM

Hi Joshua:

Sorry for the delay...I'm still on vacation in FL and have to go to a Panara Bread to use my Internet connection!

First, the primary advantages for partial classes are that it allows you to split a single class into multiple files. This might mean, for example, that you can have one team work on the user interface (UI) code while another team works on the business logic (BL) code for the same class. This also allows two separate teams to work on the same class at the same time without "trampling" on the other team's code. Partial classes has no impact on the performance of the code.

Personally, I don't use partial classes that often, primarily because I do most of my coding "alone" making the "team advantage" less meaningful to me. Also, I write code in a way that makes part of the advantage of partial classes a moot point. For example, if I had a class that had both UI and BL in it, I would redesign it into two separate classes. To me, "pure" BL code should be platform independent. That is, I should be able to hand that code over to a Mac coder using C# and have that code work unchanged. The UI code, however, will likely have different coding conventions for the way the UI works on the other platform, even if it's nothing more than the look-and-feel of the platform. This means that porting code to a new platform should only require the UI code to be tweaked...the BL code should stand without change. That's the main reason I wrote the card game stuff in the book (see Figure 10-7) that places the UI (or client) code in one class and the BL (or rules) in a different class. As a general rule, I always try to keep the UI and BL in separate classes. Also, I just don't like paging back and forth between files. True, I probably do more scrolling on a class that has a lot of code, but I suffer the "old-dog-new-tricks" problem and probably will continue with my old coding habits.

This is an H-bomb-to-kill-an-ant response, but I hope it helps.

Dr. Purdum