Are there are good uses of Partial Classes outside the webforms/winforms generated code scenarios? Or is this feature basically to support that?
Anywhere you'd have used #region
sections before probably makes more sense as separate files in partial classes.
I personally use partial classes for large classes where static members go in one file and instance members go in the other one.
EDIT: DSL Tools for Visual Studio uses partial classes.
Thus, it's a feature that many automatic generated code uses. Instead of using #region the automatic generated code goes to one file and the user code (also called custom code) goes to another and even in different directories so that the developer does not get confused with so many meaningless files.
It's good to have this choice which you can combine - but not forced to use -with inheritance
Also, it can be handy to separate the logic of some classes among several directories. Of course, for machines, it's the same, but it enhances the user readability experience.
It is in part to support scenarios (WebForms, WinForms, LINQ-to-SQL, etc) mixing generated code with programmer code.
There are more reasons to use it. For example, if you have big classes in large, unwieldy files, but the classes have groups of logically related methods, partial classes may be an option to make your file sizes more manageable.
Another possible use for partial classes would be to take advantage of partial methods to make methods selectively disappear using conditional compilation - this would be great for debug-mode diagnostic code or specialized unit testing scenarios.
You can declare a partial method kind of like an abstract method, then in the other partial class, when you type the keyword "partial" you can take advantage of the Intellisense to create the implementation of that method.
If you surround one part with conditional build statements, then you can easily cut off the debug-only or testing code. In the example below, in DEBUG mode, the LogSomethingDebugOnly method is called, but in the release build, it's like the method doesn't exist at all - a good way to keep diagnostic code away from the production code without a bunch of branching or multiple conditional compilation blocks.
// Main Part
public partial class Class1
{
private partial void LogSomethingDebugOnly();
public void SomeMethod()
{
LogSomethingDebugOnly();
// do the real work
}
}
// Debug Part - probably in a different file
public partial class Class1
{
#if DEBUG
private partial void LogSomethingDebugOnly()
{
// Do the logging or diagnostic work
}
#endif
}
As mentioned earlier, I too think this is a code smell.
If a class is so big that it needs to be split into more files, means that it is breaking the single responsibility principle and doing too many things. The large class could be broken down into smaller classes that cooperate together.
If you have to use partial classes or regions to organize code, consider if they should be in their own classes. It increases readability and you'd get more code reuse.
I find partial classes to be extremely helpful. Usually they are used to be able to extend autogenerated classes. I used them in one project with heavy unit tests. My UT classes had complex dependencies and it was not very practical to separate code across multiple classes.Of course it is better to use inheritance\composition but in some cases partial classes can be rally helpful.