Why use partial classes?

Question

In my understanding, the partial keyword does nothing but allow a class to be split between several source files. Is there any reason to do this other than for code organization? I've seen it used for that in generated UI classes.

It seems a poor reason to create a whole keyword. If a class is big enough to require multiple files, it probably is doing too much. I thought that perhaps you could use it to partially define a class for another programmer somewhere to complete, but it would be better to make an abstract class.

Answer 1

It is very useful in every scenario where one part of class is generated by some custom tool because it allows you to adding custom logic to generated code without inheriting the generated class. Btw. there are also partial methods for the same reason.

It is not only about UI but also other technologies like Linq-To-Sql or Entity Framework use this quite heavily.

Answer 2

As you say, it is often used to separate generated code. It is often nothing to do with the size of classes/files.

The benefit of separating generated code is one of style. Generated code can be pretty ugly and unreadable and would fail many coding standards (and StyleCop checks), but that's OK, no one has to read it or maintain it directly. So, if you "hide" it in another file you can focus on making sure the rest of the class is up to standard, passes StyleCop checks and so on.

Another area where I've used it is where a class implements multiple interfaces, it can be quite nice to separate the implementation in to separate files, although this is more a matter of personal preference, I've never seen any coding standards require (or prevent) this.

Answer 3

I can think of a few useful scenarios where partials make sense, most of them I am using myself in my projects:

• To separate Tool/IDE/Designer generated code from the code you are maintaining. A good example is the Form.Designer.cs file that contains the designer generated code for windows forms applications. Many other .NET formats also have some tool generated code, which can be potentially regenerated when you build your project, and thus all your custom changes will be swiped out. The separation will help you keep your code and changes safe from such automated modifications.

• When you are implementing multiple interfaces with a lot of code in the implementation. I tend to use a separate partial file for each such interface, naming it like this: {Class}.{Interface}.cs. It is easy for me to see in the IDE which interfaces the {Class} is implementing and how.

• When the class must contain one or more nested classes, especially with enough code in them to be put into a separate file. I would stick to the above pattern and use the {Class}.{NestedClass}.cs naming convention for each nested class. Similar practice is already mentioned by Virtlink's answer.

• When I write static classes which will hold extension methods. It will often be the case to provide the same extension method logic to similar classes or interfaces - like for instance Reverse on generic and non-generic collections. I would put all the extension methods for a single class or interface in a separate partial of the static class. For instance, I'd have all extension methods for the IList interface in one place, and the same methods that are for IList<T> in another file. Another approach would be to put the same method (all of its overloads) in the same partial, with all possible classes for the this parameter - like having all the Reverse implementations in one file. It depends which one would better justify the separation in terms of code volume, or some internal conventions you or your organization might be sticking to.

• I do not use this, but I've seen some C/C++ folks to like the approach I will describe here: create a partial for the class with partial methods only. This resembles the C/C++ way to define interfaces and separate the method declaration from the implementation.

• Separation by purely logical concerns. If you happen to work with a large class that combines more than one logical set of operations in itself, then you could separate each logically-related code into a separate partial. Usually existence of such classes is against the separation of concerns principle, but it is oftenly observed real-life case, especially for older codebases. Fellow user Steve Evers has mentioned them in his answer to this question, referring to them by the name god objects. I'd personally use the approach of partial classes to split the code before any refactoring of such really large files takes place, in order to ease my work and make the refactoring more transparent. This will also reduce the conflicts I will potentially cause when versioning systems like SVN are involved.

Answer 4

One of the developers where I work came up for a pretty good use for them a couple of weeks ago in the refactoring of huge God classes that have spiralled out of control and have lots of public methods: by separating the logical functions of each bit of the class into a separate partial classes you can physically separate the class into the more atomic units that should be the classes without breaking any existing functionality, allowing you to see what is common and what is not. With this as a first stage you can then more easily break the partials out into their own independent classes and implement them throughout the code base. I thought this was a nice idea.

However, in general I think that they should only be used to augment machine generated classes when writing new code.

Answer 5

I've not seen it mentioned by anyone: I use partial to put nested classes in their own files.

All my code files contain only one class, struct, interface or enum. It makes it a lot easier to find the definition for an object when the file names show the name of the thing you're looking for. And since Visual Studio tries to match the project folders to the namespaces, the filenames should match the classes.

This also means that a class NestedClass nested inside MyClass will have it's own file in my projects: MyClass.NestedClass.cs.

partial class MyClass
{
    private class NestedClass
    {
        // ...
    }
}

Answer 6

With the exception of using generated code, I have only ever seen them used in an effort to cover up for god objects. Trying to understand a new codebase or navigate through multiple source files, that are the same object, is soooo annoying.

So when you ask Why use partial classes? I answer: unless you're using generated code, don't.

Answer 7

Code organization is the only reason, but it goes deeper than it at first seems. If you have partial classes where parts are generated you can easily:

• Regenerate code without having to detect manual changes in the classes you write to (so that you don't overwrite those parts).
• Exclude the generated partial classes from test coverage, source control, metrics, etc.
• Use generated code without forcing you to base your inheritance strategy around it (you can still inherit from other classes).

Answer 8

There are also a few places where generated / implied classes are declared partial so if the Dev needs to extend them they have full access without having to mess about inheriting and overriding all over the place. Look at the generated classes in the asp.net temp area after you run a webforms site for the first time under IIS if you want to try to catch some examples.

Answer 9

I can think of a dirty use for them.

Suppose you have some classes who need common functionality, but you don't want to inject that functionality into the inheritance chain above them. Or, you have a set of classes that use a common helper class.

Basically you want to do multiple inheritance but C# no likey. So what you do is use partial to create what is essentially an #include in C/C++;

Put all the functionality into a class, or use the helper class. Then copy the helper X times and rename it partial class A,B,C. and put partial on your A, B, C classes.

Disclaimer: Yes, this is evil. Don't ever do it - especially if it will make other people mad at you.