I hate "Impl" suffixes.

Classes ending with "Impl" - I can't stand seeing these things. Usually when I see it, I find that there's a single implementation of an interface... and that's about it. What was the point? Both are named the same, with the class including the Impl suffix. It clutters your code and making it harder to get to the implementation code when you're navigating around.

Just delete the interface! It's not rocket science adding one in later on in the rare situation that you find you need two implementations.

Is there ever a good reason to do this? Is anyone still doing this who disagrees, and can provide even a weak argument in defense of this practice? I've never liked it even from when it first appeared (early Spring days? patterns craze days?), partly just because it makes you sound like a total DORK when  you try to pronounce it. (NERRRRRRD!)

At this point I'm thinking of going to total war with this practice every time I see it (i.e. refactor/remove), but... absolute positions are often wrong since rare exceptions hide everywhere. So, am I wrong?

I can't disagree with you. These are the (weak/lame) justifications I've run into:

1. That's our team convention (meaning, "Shut up")
2. We (were told / read / researched) that's a best practice (meaning, "Shut up")
3. Changing it now would mean we'd have to change it everywhere, and that's too much work (meaning, "Shut up")
4. ... blah blah blah (meaning, "Shut up")

If people would rather give you a justification for NOT changing, they're really just saying "Shut up". If I have any agency (which fortunately, I did), I just go ahead and make the switch. For me, doing what makes sense trumps consistency. If I don't have the agency, then I just suck it up.

Lou Hamers wrote:
Just delete the interface! It's not rocket science adding one in later on in the rare situation that you find you need two implementations.

I might hesitate at deleting the interface, especially if it has already been published and there's a chance that it's used outside of the current code base. Also, the interface might make it easier to test with mocks or other kinds of test doubles. I would limit the scope of test-only implementations though. These are considerations for things that sit at integration boundaries, like DAOs and such. If something is fully contained in a module and only used internally, then I'd be more willing to consider deleting the interface.

I'm curious though, what alternative are you offering to those who are attached to the "Impl" suffix?

Say someone asks "If we don't use the 'impl' suffix, how can we tell that something is an implementation of an interface then?"

How would you answer that?

For classes that represent service types and not value types, I really like them to implement a service interface, even if the class in question is the obvious standard implementation of that interface. I do this for two reasons:

First, even if the class is a good standard implementation, I'm not sure if I might not want to change the implementation in the future anyway. Swapping out the implementing class for another makes the transition between the two implementations less of a hassle in regards to source control operations. Just keep the old class until you're sure you no longer need it. If your new implementation doesn't work out, there's no need to revert any commits: Just swap the old class back in.

Secondly, I prefer mocking service interfaces over mocking service implementations. Mocking interfaces is more "portable". By that I mean you can do it with a wider variety of mocking frameworks, and even with those that don't support heavy use of reflection. That in turn speeds up unit tests, which can really add up for a large code base where a complete test run can take many tens of minutes.

However, I'm definitely not a fan of the -Impl naming scheme. I prefer an implementation of the FooService interface to be named something like StandardFooService or DefaultFooService.

Stephan van Hulst wrote:However, I'm definitely not a fan of the -Impl naming scheme. I prefer an implementation of the FooService interface to be named something like StandardFooService or DefaultFooService.

Yes, this is one case where hinting at the implementation of a class in its name is a valid exception to the general rule of names, "Choose names that express intent rather than implementation."

For example, with data related services, I might use "Jdbc" as a prefix for a JDBC implementation or "InMemory" to indicate that the implementation is, well, in memory.

If the interface is part of some published public API, yeah obviously - you're kind of stuck with it, at least without some kind of deprecation and comms process.

Junilu Lacar wrote:I'm curious though, what alternative are you offering to those who are attached to the "Impl" suffix?

Say someone asks "If we don't use the 'impl' suffix, how can we tell that something is an implementation of an interface then?"

How would you answer that?

I'd answer it by making the question not applicable. I'm thinking of a case where the interface flat out isn't needed, so the class takes the name of the interface. In this case deleting it and just referring to the concrete type is nothing but a trivial replacement. We don't even need the IDE to refactor anything - just delete the interface and rename the class without the suffix - done (assuming they're in the same package, ok so you may need to "organize imports", maybe).

Stephan van Hulst wrote:For classes that represent service types and not value types, I really like them to implement a service interface, even if the class in question is the obvious standard implementation of that interface. I do this for two reasons:

First, even if the class is a good standard implementation, I'm not sure if I might not want to change the implementation in the future anyway. Swapping out the implementing class for another makes the transition between the two implementations less of a hassle in regards to source control operations. Just keep the old class until you're sure you no longer need it. If your new implementation doesn't work out, there's no need to revert any commits: Just swap the old class back in.

Secondly, I prefer mocking service interfaces over mocking service implementations. Mocking interfaces is more "portable". By that I mean you can do it with a wider variety of mocking frameworks, and even with those that don't support heavy use of reflection. That in turn speeds up unit tests, which can really add up for a large code base where a complete test run can take many tens of minutes.

However, I'm definitely not a fan of the -Impl naming scheme. I prefer an implementation of the FooService interface to be named something like StandardFooService or DefaultFooService.

With your first point, I'm going with YAGNI on that one. It's not hard to add an interface in after the fact, IMO. And if I want to communicate that it's a service of some kind, I'd put Service at the end of the name (which is much more meaningful), or it'll at least fall under a 'service' package. The justification for not adding it "just in case" in my mind comes from the sheer amount of code bloat and technical debt that software inevitably ends up piled under. Minimizing all that junk is a top priority for me personally, way above "in the future this thing might happen". Simplicity goes a LONG way in keeping code from becoming unmaintainable over 1-2 decades, as I'm sure you're well aware.

With the second, I'd say my complaint is somewhat not applicable to that case. Test implementations are an obvious use case where you might be tempted to do this (and of course that means you do have two implementations, even if only one in production). I say it's only somewhat non-applicable because even in that case, I'd come up with a better name such as the "Default" prefix you suggested. Admittedly my argument is slightly weaker in that case.

Yep, I fully agree with your naming convention.

Yeah, guilty as charged. I've done some "Impl" classes myself, but that's mostly when I am devoid of imagination. Otherwise I'd rather not.

Critics of Java have been hard on the language in part because some people go overboard on the interfaces. I prefer to reserve them for plug-replaceable stuff and for test/live service class situations. "Impl" is a cop-out and I think a lot of people who do that were influenced by the "Ixxx" interfaces in Microsoft's OLE. Which rates right up there with Hungarian Notation as a thing better not done. Probably qualifies as Hungarian Notation, in fact.

As bad as "xxxImpl" is, ""Ixxx" with "xxx" as the implementation is worse. See the Eclipse source code for proof.