Roughly Investigating Naming of Utility and Helper Classes in Android

TL;DR

#

• The difference between Utility and Helper is ambiguous.
• Utility classes often have private constructors and expose static methods.
• There are patterns using singular forms (~Util / Helper) and plural forms (~Utils / ~Helpers) for naming Utility packages, Utility classes, and Helper classes.
• Helper classes seem to be often defined inside util packages.
• However, as long as there is a unified idea within the team regarding the naming of Utility classes, Helper classes, or their packages, and everyone is convinced, that seems fine.
• I would be happy if you could share insights like “this is how we do it in our team” m(__)m

Recently, I’ve been feeling vaguely that the difference between Utility classes and Helper classes is ambiguous.

Thinking about it carefully, I hadn’t really been deeply conscious of “Utility classes are like this” or “Helper classes are like this”. Some might ask “so what?”. The reason I started to be conscious of it is that while reading the code of a utility class in a project I’m currently in charge of, I found myself wondering “Should this function be in a utility class?”. So, I decided to summarize my thoughts first.

To state upfront, the difference and concept of Utility classes and Helper classes might differ depending on the language, platform, and perhaps even the era. This time, I am focusing on Android application development.

• “It doesn’t really cause trouble, so maybe there’s no need to be that conscious of the difference?”
• “Utility classes and Helper classes are evil!”
• “Extension functions are enough”
• “This is fruitless (ﾟ∀ﾟ)”

There might be such opinions, but I’m not paying much attention to them here. It would be really great if you could share misunderstandings, opinions, or insights like “this is how we do it in our team” in comments or via Twitter mentions/DMs!

In the First Place

#

In a project I was previously developing alone, I intended to define Utility classes as classes that define a group of static methods that do not depend on the application’s unique specifications and can be diverted to any application, and Helper classes as classes that define a group of static methods that depend on the application’s unique specifications or specific libraries. Looking back, I wasn’t always following this definition…

So, I searched for what Utility classes and Helper classes are.

First, let’s look at Utility classes. Many articles came up, but I will quote an answer from a Quora article.

What is a utility class? - Quora

A utility class is one which:

• Has no state (fields) of its own, so all the methods can be class methods (static) rather than object methods (requiring an instantiation of an object)
• Provides methods for multiple other classes (shared code)

According to the Quora answer above, a Utility class corresponds to the following:

• A class that does not manage its own state and all methods can be class methods (static)
• A class that provides methods to multiple other classes (shared code)

I’ll search for Helper classes too.

stackoverflow.com

In the stackoverflow question above, the term helper “objects” is used. Perhaps the person who wrote the question recognizes Helper classes as classes that are instantiated and used.

I quote one of the stackoverflow answers.

These are objects that “sit to the side” of the main body of code, and do some of the work for the object. They “help” the object to do it’s job.

It seems to say that helper objects sit next to the main code and take over some work for a specific object. They are objects that “help” the work of a specific object. I can somewhat understand why a Helper class is a “Helper”. In this article, I call it Helper class, but maybe Helper object is a more general term.

Referencing Android Framework Code

#

Here, I will reference Android framework’s Utility classes and Helper classes respectively.

Util / Utils

#

Search results for “util” | Android Developers

When searching for utility classes on the Android Developer site, many classes in the java.util package are hit. Instead, I’ll look at the AOSP mirror on GitHub. I’ll peek into the util package.

github.com

Focusing on the naming of the class group, I noticed the following:

• Classes with the Utils suffix are scattered here and there.
• Only one Helpers class (ContainerHelpers.java).
• Most classes do not have Utils or Helpers suffixes, such as JsonWriter, Log.
• Many have private constructors defined and are used as static classes, but classes used by instantiation are also included.

Next, let’s look at core-utils of the Support Library.

github.com

There are class names with the Utils suffix like NavUtils, ColorUtils, MathUtils, and others without it. Also, like the AOSP mirror, Helper classes (PrintHelper) are included.

Referencing Square’s OSS Code

#

Next, I will reference the source code of OSS libraries from Square, which is famous in the Android community. (I won’t describe the libraries covered here.)

OkHttp 3

#

Update 2020/08/11: This class no longer exists as of this update.

OkHttp 3 has a class named Util under the internal package.

A private constructor is defined. Although it exists under the internal package, constants and methods are public scope, so they seem callable from the application side.

/** Junk drawer of utility methods. */
public final class Util {
...

There is a comment like this. Personally, I interpret it as a class that is just a collection of utility methods.

Picasso 3

#

Picasso 3 also has a utility class. This one is named Utils.

github.com

The Utils class of Picasso 3 also has a private constructor defined, so it assumes usage only by static method calls. The Utils class of Picasso 3 seems to have the class itself and all methods in package scope. As an aside, I haven’t checked if the dependency existed originally, but you can see that Okio classes are used inside the Utils class of Picasso 3.

Okio

#

Update 2020/08/11: This class no longer exists as of this update.

Okio also has a utility class. Kotlinization work is progressing towards Okio 2, and the Util class is rewritten in Kotlin. Okio adopts the class name Util, similar to OkHttp.

Summary

#

“Summary already!? What about Helper classes!?” you might think, but my energy is running out, so I will selfishly summarize around here.

As a result of reading the source code of the Android framework and Square, which develops multiple famous OSS libraries, I personally found the following:

• The difference between Utility and Helper is ambiguous.
• It seems good if there is a unified idea within the team regarding the naming of Utility classes, Helper classes, or their packages.
• Utility classes often have private constructors and expose static methods.
• There are patterns using singular forms (~Util / Helper) and plural forms (~Utils / ~Helpers) for naming Utility packages, Utility classes, and Helper classes.
• Helper classes seem to be often defined inside util packages.

In the previous project, we defined ~Helper classes in the helpers package, but in AOSP, I was surprised to see many patterns where Helper classes are included inside the util package. I got a fluffy impression that the concept of Helper probably exists within the concept of Utility.

However, even after investigating, thoughts like “but isn’t it better to separate util package and helper package?” or ego-like obsessions like “I want to unify singular and plural forms of class names” or “I want to make package names plural” have not disappeared, so I will continue to develop with conviction while discussing with other team members.

Once again, I would be happy if you could share insights like “this is how we do it in our team”.

That’s all!