C# - What are partial classes? and when to use them? - updated 2022

I got this question during an interview and I had to admit that I had rarely used partial classes. We quickly skipped the subject, but I felt that there was something that I had missed out on in the .Net framework.

What are partial classes

In short: "Partial classes allows us to split up a class definition into several parts (partial classes)". These parts may be in different source files, or in the same file. Upon building the solution these different parts are combined into one class. Actually this can also be done to interfaces and structs (but I will stick with classes for simplicity in this post).

When the source code is compiled everything is merged. Annotations/Attributes are merged, which means the compiled class and properties will have annotations from all partial sources. The same happens to interfaces, if every partial implements a different interface, the result will be a class which implements them all. Methods defined in the different partials will also be merged.

One gotcha developers sometimes run into is that their partial classes are created in different namespaces, but partial classes must be in the same namespace. As CodingGorilla on stackoverflow puts it: "A class's name includes it's namespace, so name1.Foo and name1.name2.Foo are two completely separate types.".

Below is a visual representation of a Dog class that is made of several partial classes. The result upon compilation is they become one class with all the attributes and methods from the partial classes:

Simple example of partial classes merged upon compilation

When to use partial classes

There are a few situations where the partial keyword is ideal. Partial classes may be a rare occourence to you, but there is one situation where partial classes are very useful:

Working when with auto generated code

When some code/class is auto generated and needs to be extended. In some projects you might have auto generated code, let it be from UI or an object relational mapper (Entity Framework for example). You can then write your own partial classes to extend the auto generated code. By having your extending code in partial classes, the auto generated code does not overwrite your changes when it is regenerated, as your code resides within its own classes. This keep auto generated code and your own code separate, but keep both extensible.

A side effect is that you can leave auto generated code out of the source control, but keep your extensions. You might say that you can just extend the class using inheritance, but this will break the build on the build server unless you check in the generated code. This will also make it impossible to inherit from a specific class of your own choosing.

Multiple developers working in the same code base

Some state that you may also use partial classes to have multiple developers work on the same class without conflicts. Personally I have never found this to be an issue. Source control makes it easy to merge and having a class split over several files makes it harder to reason with the code and the end result. If the class is getting too big or is split into "subclasses" by the use of partial classes you should likely make two or more classes instead. This would also separate the concerns of the class. Even if a class is split over several files to make merge conflicts less common, two developers might still have to edit the same partial class.

That is it!

If you wish to know more about partials visit msdn.

In short: Partial classes are a way to separate your classes over several files. They make great sense when you have auto generated code which you wish to extend.

I hope you enjoyed this post, please leave a comment down below with your thoughts!