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?
7
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.
5
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:
-
You have been tasked with the refactor by a superior.
-
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.
4
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.
There are a couple of principles that apply here
-
SOLID design principles for OO
The main one that applies to your description is thesingle responsibility principle.
Although theInterface segregation principleby 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