Menu
Service able to serve some clients, and often this is a SOA specific entity. Helper provides a set of methods which commonly are pure functions.
What is Utility Class? Utility Class, also known as Helper class, is a class, which contains just static methods, it is stateless and cannot be instantiated. It contains a bunch of related methods, so they can be reused across the application. As an example consider Apache StringUtils, CollectionUtils or java.
Helper Class is a Java class which includes basic error handling, some helper functions etc. Helper class contains functions that help in assisting the program. This Class intends to give quick implementation of basic functions such that programmers do not have to implement again and again.
A Helper class is a lesser known code smell where a coder has identified some miscellaneous, commonly used operations and attempted to make them reusable by lumping them together in an unnatural grouping.
There are many naming styles to use. I would suggest Utils just because its more common.
A Utility class is understood to only have static methods and be stateless. You would not create an instance of such a class.
A Helper can be a utility class or it can be stateful or require an instance be created. I would avoid this if possible.
If you can make the name more specific. e.g. if it has sorting methods, make it XSorter
For arrays you can find helper classes like
Array
Arrays
ArrayUtil
ArrayUtils
ArrayHelper
BTW a short hand for a utility class is an enum with no instances
enum XUtils {;
static methods here
}
If you need to implement an interface, I would use a stateless Singleton.
enum XHelper implements RequiredInterface {
INSTANCE;
// no instance fields.
}
In general? It's entirely arbitrary. There are no rules for this.
A utility is a "leaf node" class of general use. That is, it doesn't have any dependencies into your project and can be ported from project to project without breaking or becoming useless. Examples: Vector3, RandomNumberGenerator, StringMatcher, etc...
A "helper" seems to be any class whose design is to aid another class. These may or may not depend on your project. If you're creating a GameNetworkClient class, you could say the GameNetworkConnection class is a 'helper', because it "helps" the GameNetworkClient.
The way developers refer to tools reflects common usage of these words. If you can recall hearing tools described as "helpful" vs "useful", a helpful tool tends to have some context (cheese grater helps to grate cheese, corn stripper helps to strip corn, speed loader helps to reload a firearm). A "utility" is expected to work in a variety of contexts (WD-40, duct tape, army-knives, glue, flashlight, etc...).
As Jesper said, it's entirely arbitrary. You can think of what works for your organization and make that the convention.
For me, it's something like this:
utils - Static class, that can be freely moved and imported anywhere.
Doing general tasks that could be useful in different modules. As Peter Lawrey said, more specific names are useful.
helper - Class helping another class or a module.
Tasks that are only used in the module it's placed and won't make sense to be imported elsewhere. Hence the name could be more specific - ModuleNameHelper (e.g. AdministrationHelper, LoginHelper)
There's no ultimate answer for this. Figure out one naming scheme and stick with it. Naming your packages and classes is an important part of software architecture, and nobody can take that decision away from you.
I personally like the XHelper better, but I see XUtils more often in foreign code.
I also like the "plural" naming scheme you will find both in the JDK and Guava:
if a class deals with Collection objects, it's called Collections
Array > Arrays (jdk)
List > Lists (guava)
Map > Maps (guava)
etc.
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