Using Partial Classes to manage code, good solution?

Question

Books usually say that if the classes get too big to manage, rethink the implementation because it is quite possible that the design needs correction since classes have not been defined properly.

But in situations where classes are indeed big, for example when a class is being extended to implement the functionality of a control (Canvas for example), and there are many different things like hit-testing, drawing, managing the drawn items etc. Is it a good solution to use partial classes in such cases to separate 'different' things of a bigger container (such as a custom control)?

Secondly, as a more general and broader solution, what should be considered before moving to Partial classes?

Answer 1

Yes, if the class is naturally large, using partial classes can help you manage the source code. I've used this before now to split the tests for a single production file into several source test files. Likewise when reimplementing LINQ to Objects, I used partial classes to put each LINQ "operator" in its own file - even though they all contributed to a class called Enumerable.

Partial classes aren't a good alternative to good design though - when you can make your actual classes smaller, it's worth doing so. If you find you've got a bit class which you want to break up, partial classes can help you to refactor the big class into two smaller classes - you can divide the class into two sections without changing the functionality at all, then perform the real split in a smaller step.

Answer 2

It's an illusion. It's just separating the class into two physical files. You still run afoul of the Single Responsibility Principle, low cohesion, etc.

Partial classes are primarily intended for use with automated code generation tools. You can edit the partial class without worrying about it being overwritten when the other portion is regenerated by the tool.

Composition is one of several ways to avoid large classes. Class A has an instance of class B, and delegates to it for part of its functionality. In many cases dependency injection can be used to decouple the two classes (class A is passed an interface that class B implements, usually in A's constructor).

Answer 3

Hit testing seems not to be a task for a canvas and can easily be delegated to another class implementing an interface like

public interface IHitTester
{
    List<Shape> GetHits(List<Shape> allShapes, Point point);
}

It enhances testability, allows you to experiment with different hit testing implementations (strategy pattern) and enhances the readability of your code.

I am sure that you can extract other tasks to other classes in the same way, if you rethink your canvas class.

Answer 4

I think the use of these outside of code generation is a total anti-pattern. They are more or less equivalent to Regions which again were for code generation. I see some developers using them for aesthetic reasons and calling their use refactoring! When you try to find the definition of a class and are presented with serveral partial classes to chose from it's not very helpful. I think developers should use split window to open the same file twice instead of shuffling parts of the class into different files.