Sometimes I wonder what motivates language developers to make some of the design choices they do. In fact, I’d like to arrange events called Authors Summits, where the language vendor, such as Microsoft, explains its decisions directly. Imagine gathering about 200 authors in a room. There is Dan Appleman and Charles Petzold. Dave Chappell is presenting with Chris Sells. Over by the coffee table are Carl Franklin and Rocky Lhotka having a danish. And I am in the back furiously taking notes to prepare an article or a proposal for a new book. I politely raise my hand.
Paul: What was the motivation behind partial classes?
Chris: Well, VB programmers were used to a very clean form code-behind experience, and partial classes allow us to separate out all of the plumbing that the .NET form designer adds to forms and give VB.NET programmers the clean experience they were used to.
Paul: So, that was pretty much it.
Later I see Dan Appleman and ask him the same question. (Dan has a way of saying things that are true and painful without seeming too offensive.) He says that Microsoft was trying to figure out how to outsource code projects to India without releasing proprietary information. With partial classes, Microsoft can send obfuscated assemblies to India without exposing proprietary information—while taking advantage of the lower wage rates.
Paul: How is that working?
Dan: Not too good. The Indians are smart to be aggressive about scope creep, which makes it very hard to change requirements midstream. So, if something comes back wrong, a debate about scope creep ensues.
Paul: That’s clever. Claiming scope creep is a way to get paid without really delivering, sort of.
Dan: Yeah, it’s a real problem.
Paul: Does the partial class obfuscation strategy work technically?
Dan: Yeah, so far so good, but if one big chunk of critical code is de-obfuscated then there will be big problems for everybody.
[Disclaimer: No actual authors were harmed during this dramatization, and Dan Appleman is a fictional character who is not intended to represent any real person.]
Guidelines for Using Partial ClassesPartial classes, like any new construct, come with rules for using them. The help function serves this purpose. I have included a summarized list of the most notable partial class rules to support Listing 1, which demonstrates two partial classes.
Listing 1: A Partial Class Containing Two Parts
Partial Public Class PartialClass
Public Shared Sub Main()
Dim part As New PartialClass
Partial Public Class PartialClass
Public Sub WhoAmI()
Console.WriteLine(“I am PartialClass”)
Pretty easy, really. The partial classes use the new keyword partial and are defined in the same namespace. However, partial classes can and probably should be defined in separate physical files. Other rules or limitations are:
- Partial classes can be used to split the definition of classes, structures, and interfaces, which supports simultaneous development or the separation of generated from user-generated code.
- Each part of a partial class must be available at compile time.
- Partial classes must use the same access modifier (e.g. Public Protected, Private).
- If any single part is abstract (MustInherit), then the whole class is abstract.
- If any parts are sealed (NotInheritable), then the whole class is sealed.
- If any part declares a base type, then the whole class inherits that base type.
- Parts can specify different interfaces, but the whole class implements all interfaces.
- Features defined in any part are available to all partials; the whole is the sum of all of the parts.
- Delegates and enumerations cannot use the partial modifier.
- Attributes apply to all parts.
This list may seem like a lot to remember, but just think of partial classes as a class definition split across many files for convenience. The next section presents a brief scenario that may help you get some extra mileage out of partial classes.
Problem Resolution ScenarioThe notion of eXtreme Programming has some interesting concepts. Some, like pair programming, bug me because programmers are all smart and there seems to be too much debate going on—at least for all of the pairs I have seen. However, a derivative of this concept might work well.
Along the same lines, SourceSafe is a relatively useful tool. However, sometimes it seems hard to use because of real or perceived problems that may occur during multiple file checkouts. Suppose you and I have a file checked out at the same time. You check your changes in, and I check my changes in. Are you completely sure that all files—including text and binary—are merged correctly? No. Well, you are not alone.
With partial files, we could name our various source code files Foo1, Foo2, and Foo3, each of which contains the same class, Foo. You work on one part (say fields, properties, and events), while I work on another (methods) and a third developer works on implementing interfaces. Now we can check in or out our various files without ever having to check out the same file simultaneously. Problem solved.
In addition, with a little upfront design work and some simple naming conventions, the three of us can reduce or eliminate minor problems. For example, make one person responsible for the class modifiers, attributes, and inheritance. Or, better yet, have one person stub the classes and agree not to unilaterally change the class header. This kind of collaboration could yield some good returns and ensure that remote developers and telecommuters don’t make code changes that contradict changes made by office workers.
The Good Housekeeping FeaturePartial classes is pretty good idea. It cleans out the code-behind, separating designer code from user-written code, and anything that aids in housekeeping is a good thing.
You aren’t required to use the partial modifier in code you write, but you will see it used in Forms and Controls by the designers. What the partial modifiers mean is that under most conditions you don’t need to change the designer-generated code; simply add your code to the source file provided and let the designer take care of itself.
About the Author
Paul Kimmel has written several books on object-oriented programming and .NET. Check out his upcoming book UML DeMystified from McGraw-Hill/Osborne (Fall 2005). Paul is also the founder and chief architect for Software Conceptions, Inc., founded in 1990. He is available to help design and build software worldwide. You may contact him for consulting opportunities or technology questions at email@example.com.
If you are interested in joining, sponsoring a meeting, or posting a job, check out www.glugnet.org, the Web page of the Greater Lansing area Users Group for .NET.
Copyright © 2005 by Paul T. Kimmel. All Rights Reserved.