What are the pros and cons of making a FAT class a partial one & splitting it into partial classes?

Question

Recently I was considering a class that seems to become fat because of too many methods in it.

A legacy code...

That has many business logic-wise methods doing all types of CRUD on various 'Etntities'.

I was thinking

1. make this class partial
2. and then grouping all methods by their target entities they work on
3. and splitting them into separate physical files that will be part of the partial class

Question: Can you list pros and cons of such a refactoring, that is making a fat concrete class a partial class and splitting it into slimmer partial classes?

Answer 1

One pro I can think of is the reduction of conflicts/merges in your source control. You'll reduce the number of parallel check-outs and the merging headaches that invariably come when the devs check-in their work. A big pro, I think, if you have a number of devs working on the same class quite often.

Answer 2

I think that you are talking only about simplicity to handle the class. Performance or behaving pros and cons shouldn't be because when compiled it should generate the same result:

It is possible to split the definition of a class or a struct, or an interface over two or more source files. Each source file contains a section of the class definition, and all parts are combined when the application is compiled.

Now answering pros and cons I can think in (only about simplicity):

• Pro: less conflicts / merges if working in a team.
• Pro: easier to search code in the class.
• Con: You need to know which files handles each code or it can get a little annoying.

I would go for the refactor. Specially considering all facilities given by the IDE where you just have to click F12 (or any other key) to go to a method, instead of opening the file.

Answer 3

Splitting a large class into partial classes perhaps makes life easier in the short term, but it's not really an appropriate solution to the code bloat that your class is experiencing.

From my experience, the only benefit that splitting an existing large class up gives you is that it's easier to avoid having to constantly merge code when working with other developers on said class. However, you still have the core problem of unrelated functionality being packaged into one class.

It's better to treat the breaking down to partial classes as the the very first step in a full refactoring. If you're able to easily extract related methods and members into their own partial classes (without breaking things) then you can use this as the basis for creating entirely standalone classes and rethinking the relationship between them.

Edit: I should clarify that this advice is given under the assumption that your legacy code has unrelated functionality in one class as a result of years of "just add one more method here". There are genuine reasons for having functionality spread across partial classes, for example, I've worked on code before that has a very large interface in one file, but then has all the methods grouped into partial classes based on areas of product functionality - which I think is fine.

Answer 4

I would say Partial class would help to maintain the code and will be more helpful when we have legacy code to avoid more changes on the reference side. Later will help to refactor easily

Answer 5

If you're concerned about how to refactor a class, I suggest reading into SOLID design principles.

I think you should focus on Single responsibility principle (the S in SOLID), which states an object should only have one responsibility.

I think my answer is not directly answering your question whether using partial classes would be beneficial to you, but I believe if you focus on the SOLID design principles that should at least give you some ideas on how to organize your code.

Answer 6

I see partial classes only as a way of extended a class that's code was generated (and can be re-generated at any time) that you would like to extend without your custom code being overwritten. You see this with the Form generated code and Entity Framework DbContext generated code for example.

Refactoring a large legacy class should probably be done by grouping and separating out single responsibilities into separate classes.