1

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?

pencilCake
  • 51,323
  • 85
  • 226
  • 363

6 Answers6

3

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.

Big Daddy
  • 5,160
  • 5
  • 46
  • 76
  • +1. Also it makes thigns easier to navigate, when you do it logically (for example a partial class for every implemented Interface). – TomTom Jan 10 '13 at 14:37
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.

Diego
  • 16,436
  • 26
  • 84
  • 136
  • Well said, especially the performance side- no difference, this is all a compiler trick (and compilation rarely is relevant in terms of time for a class to even count there) – TomTom Jan 10 '13 at 14:48
0

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.

Chris McAtackney
  • 5,192
  • 8
  • 45
  • 69
  • -1 for first sentence. There are sometimes reasons for that (class MUST implement 30 interfaces, all with half a dozen methods) and sometimes - like in the OP case - this is legacy code. "refactor the whole class" is totally different from "split the code for easier maintainability". – TomTom Jan 10 '13 at 14:49
0

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

Mohammed Igbal
  • 11
  • 2
-2

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.

Matthew
  • 24,703
  • 9
  • 76
  • 110
  • I will give you a -1 here because there is this Thing like requirement and some - not many - classes are Hugh for a lot of reasons. The Windows Forms WINDOW class Comes to my mind. SOLID is all nice and Dandy, but it may not be possible to refactor THAT for a good number of reasons. Like legacy code - as the OP says. – TomTom Jan 10 '13 at 14:35
  • The question itself does not indicate the state of the code in question. The quote "That has many business logic-wise methods doing all types of CRUD on various 'Entities'." leads me to believe that it might be useful to split it up based upon functionality. It should be up to OP to decide whether that is a reasonable thing to do, instead of us readers assuming requirements for him. This is why my answer was open ended, because I didn't want to assume his requirements and motivation for making such changes. – Matthew Jan 10 '13 at 14:49
-2

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.

Quinton Bernhardt
  • 4,773
  • 19
  • 28
  • -1 because it is obviously not true. It is totally valid to have 10 separate files for a class. We often do that along Interfaces (type.interface.cs) to Isolate Interface implementations. NOTHING in partial class says "only for code Generation". – TomTom Jan 10 '13 at 14:36
  • I agree with separate classes; but I consider the big effort behind it and a possibility to break an already working code. I was thinking by going with partial classes: 1) I would at least make it more readable 2) And stay away from the risk of breaking something – pencilCake Jan 10 '13 at 14:36