Menu
I have a Java class that is becoming long. When I run it through code quality tools, I get flagged for number of lines in the class.
This is a lower layer class, used by upper layers with Spring's @Autowired. The class has a lot of private instance methods which are not static. They don't use any instance fields, working only on method parameters.
Can I safely move these methods as public static in some separate utility class? What are the downsides?
777
1 Answer. I prefer such helper methods to be private static; which will make it clear to the reader that they will not modify the state of the object.
Helper methods are often declared as public static so they can be invoked with the class name like Classname.
A utility class is a special case of a helper class in which the methods are all static. In general, helper classes do not have to have all static methods, but may have instance variables. Multiple instances of the helper class may exist as well.
Thirdly a non-static private method can be called from a constructor of the class also, it need not be static. Now coming to your question if a private helper method should be defined as static or non-static.
Some will insist Utility & Helper classes are different, while others will insist they are the same. They certainly share a number of features in idiomatic Java. All their methods will be static, so it will make no sense to instantiate the class, This will be prevented with a constructor that is private and/or throws an exception.
If a variable or methods or constructor is declared as private then we can access them only from within the class i.e from outside the class we can’t access them. This modifier is applicable for both top-level classes and interfaces.
In Java, public and private are keywords that are known as an access modifier or specifier. It restricts the scope or accessibility of a class, constructor, variables, method s, and data members. It depends on which it is applied. Java provides the four types of access modifiers: public, private, protected, and default.
"Wrong" mindset here.
You do not rework your classes because tools are complaining about this or that.
You want to improve the quality of your source code; and such tools can help with identifying "topics worth thinking think about". You take their feedback as hint; not as "order".
Therefore you don't worry about "lines of codes" within a class. Instead, you worry about the responsibilities that this class has. Meaning: the line number count isn't a problem per se - but violations of the Single Responsibility Principle are.
Thus: you step back and check out what exactly your class is doing. And when it is clearly doing more than one thing, you extract such aspects into other classes!
Meaning: if you actually find that all this code "belongs" to the responsibility of that class; then keep it in there. Don't start putting internal implementation details into unrelated helper classes; just because some tool warns you about number of lines.
On the other hand, turning private methods into something that is static/package protected would allow you to unit test those methods. Which could be an advantage. But as said: as long as we are talking about implementation details, they should stay private; and they shouldn't be unit tested anyway.
Long story code: know and understand what "clean code" is about; and try to follow the ideas outlined there.
56
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
