Allowing multiple developers to work on a single class at the same time without the need for later merging files in source control.
Allowing a separation between the class interface and the implementation-related definitions (Separate definitions of the public and private parts)
Easing the writing of code generators, such as visual designers. This is perhaps the most useful reason. It is a challenge to develop code generators that can manage the generated code when it is placed in the human-written code:
Requires a lot of parsing of unnecessary code, just to find a place to insert the generated code. Altering the code is also a problem. Poorly written generators hold the potential risk of damaging the entire file.
Human programmers tend not to like the looks of generated code, and thus like to "tweak and tune" it, so it looks better, conforms to their standards, or is better optimized. All in all, it's best not to let human-programmers see the code at all.
Using partial classes, the code generator processes a separate file, and is thus alleviated from all the above mentioned problems.
The implementation of partial classes is quite straight-forward and architecture-transparent. When compiling, the compiler performs a phase of precompilation: first it "unifies" all the parts of the partial class into one logical class, and from that point, normal compilation takes off.
Simple example in VB.NET
This simple example, written in Visual Basic .NET, shows how parts of the same class are defined in two different files.file1.vb:
When compiled, the result is the same as if the two files were written as one, like this:
Separation of concerns
Partial classes also support the separation of concerns . The following Bear class has different aspects implemented in different parts.Bear_Hunting.cs:
For example, if we want to compile a version without support for hunger management (it could be a feature that costs extra for your customers), we simply remove the partial declaration in Bear_Hunger.cs.
Now if a program also supported hunger management in other classes all those partial class definitions could go in a separate 'Hunger' directory. This is what is usually called multidimensional separation of concerns, and it helps programmers update the code and add new features, even the first time anyone started working with this code.
Separation of concerns in Ruby
The usage of partial classes is subject of criticism and thus not broadly adopted in object oriented languages and rarely used in older programming languages like Smalltalk or C++.
Partial classes break the concept of a class being a single entity with a single concern. Partial classes change that concept and introduce parts of classes being a single entity with a single concern.
Partial classes will likely lead to large classes in different files but with many concerns - such classes are generally hard to understand and to be avoided to reduce maintenance efforts.
Separation of concerns should preferably be done by separating concerns in single classes. If classes (made up of several partial classes) have several concerns they will have to be touched & deployed whenever such a concern changes
Partial classes try to solve problems that are already solved by other more sophisticated means:
Revision control systems allow multiple developers to work simultaneously on a single class - if they don't touch the same method (as with partial classes) they don't need to merge.
Interfaces are used to separate a classes interface from its implementation
Code generators, such as visual designers should generate code that is independent of manually written code - i.e. they generate classes that have not to be touched by developers. Developers just hook up to these classes using common techniques like events, dependency injection or simply derivation
Aspect oriented programming allows to separate concerns that are usually not easily separated by conventional means. AOP does this on a much deeper level than partial classes e.g. even allowing to extract concerns like logging or transaction handling out of the methods.