7

I've heard time and time again that in object-oriented programming, you should try to split objects that 'do too much' into multiple classes, to avoid the "God Object" problem.

This seems like fine advice for a project that has plenty of room to expand, but in our project, our packages are already loaded down with too many objects - some that are very bare-bones - while we also have the problem of very large objects that do too much.

Is it a better idea, for code sanitation, to split our larger objects that do too much work into smaller objects? Or is there a limit to the amount of good it can do?

Zibbobz
  • 1,522
  • 3
  • 13
  • 20
  • 2
    What do you mean by "too many objects"? Do you have any objective standard for that judgement? – Charles E. Grant Apr 27 '15 at 17:50
  • see also: [How do I prove or disprove “god” objects are wrong?](http://programmers.stackexchange.com/questions/178317/how-do-i-prove-or-disprove-god-objects-are-wrong) – gnat Apr 27 '15 at 17:52
  • @gnat Having read the question, it seems to be about writing new code, rather than refactoring it. And also approaches the topic from the perspective of defining the responsibility of a single object, rather than the limits of trying to break apart objects that appear too large (though it is related - in that the answer is based upon single-responsibility principle). – Zibbobz Apr 27 '15 at 18:02
  • I've successfully used the concept of [partial classes in C#](https://msdn.microsoft.com/en-us/library/vstudio/wa80x488%28v=vs.110%29.aspx) to "split" some larger classes into multiple _files_ without the need to really actually create new classes. Probably not the most elegant way; for me it worked quite well. – Uwe Keim Apr 27 '15 at 21:02
  • 4
    *Is it always a good idea* -- It's a good idea not to use "always". There are instead rules of thumb to which one should always pay attention, but don't get carried away. Even the much maligned `goto` has it's place. – David Hammen Apr 27 '15 at 21:09
  • 1
    @UweKeim: `partial` classes are historically used to split classes into two parts: a code-generated part that is not modifiable, and a user-defined part that is modifiable. – Robert Harvey Apr 27 '15 at 21:19
  • @RobertHarvey I've "misused" it to have multiple parts of a larger class, e.g. 4 or 5 partial files of one class. – Uwe Keim Apr 27 '15 at 21:39

4 Answers4

23

It seems to me that the fundamental principle to apply here would be the Single Responsibility Principle. Does each class have a single, clearly articulated, well-bounded responsibility?

Note that I don't mean "does each class do one thing." For example, a repository "Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects." But it still might have several methods that accomplish parts of this overall responsibility.

If you find that a clearly-articulated, well-bounded responsibility that should be contained in a single class with multiple methods is instead being split over many smaller classes, then your classes are getting too small.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • How many lines would be too small? – Menelaos Mar 31 '16 at 11:33
  • The number of lines that would cause you to have too many classes. The number of classes that would make the project difficult to navigate. – Robert Harvey Mar 31 '16 at 14:32
  • It seems that there is room for a subjective opinion on what the strict min-max range should be. Searching on the net I feel ideal class size may be be a ideological/philosophical issue as well. Personally, I am ok with 400 lines of code in a class... others want 30 to 100 :S – Menelaos Mar 31 '16 at 14:34
  • 2
    Sure. But we have classes with 400 to 500 lines of code where I work now. They're too large; they already have several different responsibilities when they should only have one. A lot of the code is scaffolding; it doesn't do much in the way of real work, and a couple of functions are endlessly duplicated among the family of classes in question. So there's plenty of room for improvement. – Robert Harvey Mar 31 '16 at 14:35
  • Only 400 - 500? Lucky you... [looks at 6670 lines of legacy per class] – Juha Untinen Apr 04 '19 at 12:18
6

I assume you're on a legacy project where you weren't the one who developed the code. I am in a similar situation.

In my opinion, don't touch the code unless:

  1. You have been tasked with the refactor by a superior.

  2. You are in fact a senior guy who knows the code inside and out.

Otherwise I would have to say I would apply the "if it isn't broke, don't fix it" law. While it is quite possible that you may achieve better modulation and encapsulation by breaking up huge classes, it could also introduce tons of problems that are not there currently.

Lawrence Aiello
  • 1,398
  • 11
  • 12
  • It is in fact Legacy code. I've been waiting on a database update to test some of my assigned changes and was considering doing some refactoring (I don't know the database well enough, or have the authority enough, to make those database changes myself). – Zibbobz Apr 27 '15 at 17:53
  • 2
    @Zibbobz don't refactor unless it's required by your assignment (iow, it's explicitly your task or you're working on a problem involving the code you want to refactor directly and refactoring will save time on your task). Unless you're the person setting the budgets and tasks it's not up to you to decide that refactoring should be done. You can of course let your team lead or whomever is responsible know that in your opinion refactoring would be a good idea and they can then consider it for the future. – jwenting Apr 27 '15 at 18:55
  • While this is good advice, it has little to do with the question that was asked. I'm not downvoting, just commenting. – Matthew James Briggs Apr 27 '15 at 19:33
  • I do agree this doesn't answer the fundamental question of whether it's better to break large classes down when they seem too big, but it is great advice. The biggest problem I see in open source is that too few suggestions come from those who took the time to analyze the current code first. – Abandoned Cart Oct 26 '21 at 10:51
2

Is it a better idea, for code sanitation, to split our larger objects that do too much work into smaller objects?

It is not about the length of the class but about the responsibility.

You could potentially have a class that is a bit too long but is taking care of only one responsibility. So, definitely don't go by length.

Instead, try to understand the problem it is trying to solve.

If it is solving a single problem then it is following the single responsibility principle and you could either leave it the way it is or DI some of its private methods as helpers classes.

If you notice that it is taking care of more than one responsibility then no matter how long the class I would suggest to break it down into two or however many responsibilities it takes to have them all take care of singular concerns.

AvetisCodes
  • 1,544
  • 3
  • 14
  • 26
0

There are a couple of principles that apply here

  • SOLID design principles for OO The main one that applies to your description is the single responsibility principle. Although the Interface segregation principle by its nature tends to keep class sizes reasonable.

  • Refactoring Question So whilst it is better to keep classes smaller, the decision to refactor is a more cokplex one.

    Do you have good Test cases.
    With good test cases you can be more adventurous with refactoring . But as usual if the original developers were getting OO build done with a good set of test classes, then they would have already refactored.

    Did the large class need to be changed? If you have to change of fix something, that is often a point were a refactor can be worth the investment.

    Refactoring to make it more elegant As much as it is nice to have clean and more easily maintained code, without sufficient maintainability issues it is most likely hard to justify refactoring for elegance.

When to refactor Blog, worth a look

if you happen to have a pluralsight subscription, there is an excellent course on this topic refactoring on plural - subscription fee applies

phil soady
  • 246
  • 1
  • 4