This past weekend, while refactoring some of my Twitter library’s code, I discovered the “partial” keyword in C#.  Granted this things probably been around for a while, it really helped me organize my methods in my Twitter class into an organizational scheme that made more sense and followed the structure that Twitter uses in their API documentation.

Lets take a look at the partial keyword in a little more detail.Lets say I have a single class that will contain a log of methods.  Opening this one class file every time I need to make a change means I have to see a bunch of unrelated methods every time my code breaks or I have to edit it.

If you’ve heard about the SOLID principles then you know that the “S” stands for “Single Responsibility” which means that a class should have a single reason to change.  Now there are times when a class is going to contain a lot of methods because those methods are in fact related a higher level but might not directly relate.  This is where the partial keyword comes into play.  I can organize my methods so that related methods are in their own files but are still accessible in the same class.  This came in real handy in my Twitter library (linked above).

Lets look an example using some code excerpts from my project.  We’ll start with looking at all the methods in a single class.

[csharp]
public class Twitter
{
public IList<StatusMessage> GetFavorites(StatusRequestOptions statusRequestOptions)
{
//Code Ommited
}

public StatusMessage MarkAsFavorite(long statusId)
{
//Code Ommited
}

public StatusMessage DeleteFavorite(long StatusID)
{
//Code Ommited
}

public IUser TurnDeviceNotificationsOn(StatusRequestOptions statusRequestOptions)
{
//Code Ommitted
}

public IUser TurnDeviceNotificationsOff(StatusRequestOptions statusRequestOptions)
{
//Code Ommitted
}
}
[/csharp]

You can see that I have two different areas of interests here: Favorites and Device Notifications. If Twitter makes a change to their device notification API section, I shouldn’t have to worry about the Favorites related methods and if I leave all of this in the same file I’ll see the Favorites methods when I make changes to the Device Notification methods. This is mentally taxing and should be avoided. Lets look at my newly refactored code that takes advantage of the partial keyword. I now have two files: FavoritesMethods.cs and NotificationMethods.cs.

FavoritesMethods.cs looks like:

[csharp]
public partial class Twitter
{
public IList<StatusMessage> GetFavorites(StatusRequestOptions statusRequestOptions)
{
//Code Ommited
}

public StatusMessage MarkAsFavorite(long statusId)
{
//Code Ommited
}

public StatusMessage DeleteFavorite(long StatusID)
{
//Code Ommited
}
}
[/csharp]

And the NotificationMethods.cs will look like:

[csharp]
public partial class Twitter
{
public IUser TurnDeviceNotificationsOn(StatusRequestOptions statusRequestOptions)
{
//Code Ommitted
}

public IUser TurnDeviceNotificationsOff(StatusRequestOptions statusRequestOptions)
{
//Code Ommitted
}
}
[/csharp]

As you can see, this is much easier to keep track of. It also organizes the methods into files containing related methods. So when I have a problem or need to make a change, I’m only concerning myself with the methods at hand and not 50 or 60 other unrelated methods. Sure, you can probably keep the other methods out of your head if they’re all in the same file, but you’ll see them and thus you’ll become aware of them mentally. Using the partial keyword on your class will allow you to organize your methods in a way that makes sense while maintaining that they are part of a much larger class when being used in an application.