Header background

The Force of interfaces and meaningful class names: Don’t Be a Sith

In a galaxy far, far away, there’s a disturbance in the Force. It’s a practice that’s as limiting as the Sith Rule of Two: “Always two there are, no more, no less. A master and an apprentice.” The convention I’m referring to is naming Java classes with a trailing Impl.

The dark side of IMPL

Imagine you have an interface, InputHandler. The dark side tempts you to name the implementation InputHandlerImpl. This is a trap! It’s as restrictive as the Sith philosophy, limiting the potential of your code because it implicitly suggests there should only be one implementation of that interface.

The IMPL suffix lures developers into the wrongful thinking that only one implementation of that interface should exist.
The IMPL suffix lures developers into the wrongful thinking that only one implementation of that interface should exist.

Embrace the light side with descriptive naming

Instead of succumbing to the dark side, let’s embrace the light side of the Force. The name of the implementing class should start with Default. Better yet, it should include some information about why this class exists.

So, instead of InputHandlerImpl, maybe consider DefaultInputHandler. This small difference opens your mind and leaves room for further implementations, if necessary. Even better options are HttpInputHandler or StreamingInputHandler, as these document technical details that add real value to the name.

The power of many can bring about change.
The power of many can bring about change.

This approach aligns more with the Jedi way, allowing multiple Padawans to learn and grow, just as multiple classes can implement the same interface, each with unique characteristics.

This method not only keeps your mind open to additional implementations but also provides more insight into the technical details of the code. Just browsing through the classes of the code allows anyone to learn about the protocols and technologies automatically.

Don’t be a Sith, be a Jedi

Remember, restricting interfaces to one implementing class is like the Sith, where there can only be one master and one apprentice. But in software development, we want to be more like the Jedi, embracing diversity and learning from different implementations.

So, fellow developers, let’s not be Sith, limiting ourselves to a single Impl. Let’s be Jedi, mindfully leveraging the vast possibilities of descriptive class naming. May the Force (and good coding practices) be with you!

Learn more about software engineering at Dynatrace.