Hi Suraj, If the class author's intention was to create a utility class then I would support demonstrating this by using the private constructor.
The Lombok project briefly describes the case they support with the @UtilityClass [1]. Private constructors for utility classes also appears in Effective Java [2]. I'm not sure I would extend the definition of Utility Class to cover things like PartyServices, though. I would prefer utility classes only contain functional code - i.e. no side effects - which cannot be the case for services. Summary - if a class is a genuine utility class, then we should probably treat it as such by implementing the private constructor and marking the class final. I'm not sure about whether the same approach should be applied to non-utility classes that happen to only have static methods. Thanks, Dan. On Wed, 22 Apr 2020 at 16:02, Suraj Khurana <suraj.khur...@hotwax.co> wrote: > Hello team, > > While checking codebase using QAPlug [1], it is suggesting to 'Make sure > that utility classes (classes that contain only static methods) do not have > a public constructor' as an efficiency enhancement. > > According to it, all our services, events, helper, worker classes which are > mostly in JAVA should be having a private constructor and must be defined > as 'final' so that the JVM doesn't need to create a data object using that > default constructor everytime and supplies which is time taking. > > Please let me know your thoughts on this. > > [1]: https://qaplug.com/ > > -- > Best Regards, > Suraj Khurana > Senior Technical Consultant > -- Daniel Watford
