C# Partial Keyword

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.

Advertisements
This entry was posted in programming and tagged , , , . Bookmark the permalink.

6 Responses to C# Partial Keyword

  1. Congratulations, you've just abused the partial keyword :)In all seriousness, partial is really only useful for extending classes that contain generated code. The generated code stays in one file, you modify another.Your scenario here shows that the Twitter class is doing way too much. You should break this up into separate classes, each with 1 responsibility.You might end up with a Twitter class that is a simple gateway into a deeper object model.

  2. Michael Koby says:

    Funny that you mention that I should probably move stuff out of the Twitterclass, as it's something I've been considering for a while but haven't comeup with something that makes sense to me. It'll happen eventually, butwhatever I do, I need to make sure I understand it and why there's value init rather than just doing it because it' simply “better”.But again, I agree, the Twitter class is most definitely doing too much andneeds a better design.

  3. Peter says:

    The 140-character limit is getting to me, so I'll leave a comment here as well.I think that even if you can't split the methods of your Twitter class up because you have to have one class that represents the API, that's fine. But consider making those methods one-line stubs that call methods in other classes where all the REAL work is done. That if nothing else will shrink the Twitter class–if not by methods, then by lines of code.Also I don't know if the Twitter library has any state at all, so it may not make much sense to split the big class up into a bunch of smaller ones–some things lend themselves to OO better than others.

  4. Congratulations, you've just abused the partial keyword :)In all seriousness, partial is really only useful for extending classes that contain generated code. The generated code stays in one file, you modify another.Your scenario here shows that the Twitter class is doing way too much. You should break this up into separate classes, each with 1 responsibility.You might end up with a Twitter class that is a simple gateway into a deeper object model.

  5. Michael Koby says:

    Funny that you mention that I should probably move stuff out of the Twitterclass, as it's something I've been considering for a while but haven't comeup with something that makes sense to me. It'll happen eventually, butwhatever I do, I need to make sure I understand it and why there's value init rather than just doing it because it' simply “better”.But again, I agree, the Twitter class is most definitely doing too much andneeds a better design.

  6. Peter says:

    The 140-character limit is getting to me, so I'll leave a comment here as well.I think that even if you can't split the methods of your Twitter class up because you have to have one class that represents the API, that's fine. But consider making those methods one-line stubs that call methods in other classes where all the REAL work is done. That if nothing else will shrink the Twitter class–if not by methods, then by lines of code.Also I don't know if the Twitter library has any state at all, so it may not make much sense to split the big class up into a bunch of smaller ones–some things lend themselves to OO better than others.

Comments are closed.