Default vs Impl when implementing interfaces in Java

Question

After reading Should package names be singular or plural? it occurred to me that I've never seen a proper debate covering one of my pet peeves: naming implementations of interfaces.

Let's assume that you have a interface Order that is intended to be implemented in a variety of ways but there is only the initial implementation when the project is first created. Do you go for DefaultOrder or OrderImpl or some other variant to avoid the false dichotomy? And what do you do when more implementations come along?

And most important... why?

Answer 1

Names have the opportunity to convey meaning. Why would you throw away that opportunity with Impl?

First of all, if you will only ever have one implementation, do away with the interface. It creates this naming problem and adds nothing. Even worse, it could cause trouble with inconsistent method signatures in APIs if you and all other developers aren't careful to always use only the interface.

Given that, we can assume that every interface has or may have two or more implementations.

• If you have only one right now, and you don't know in what way the other may be different, Default is a good start.

• If you have two right now, name each one according to its purpose.

  Example: Recently, we had a concrete class Context (in reference to a database). It was realized that we needed to be able to represent a context that was offline, so the name Context was used for a new interface (to maintain compatibility for old APIs), and a new implementation was created, OfflineContext. But guess what the original was renamed to? That's right, ContextImpl (yikes).

  In this case, DefaultContext would probably be ok, and people would get it, but it is not as descriptive as it could be. After all, if it's not offline, what is it? So we went with: OnlineContext.

---

Special case: Using the "I" prefix on interfaces

One of the other answers suggested using the I prefix on interfaces. Preferably, you don't need to do this.

However, if you need both an interface, for custom implementations, but you also have a primary concrete implementation that will be used often, and the basic name for it is just too simple to give up to an interface alone, then you can consider adding "I" to the interface (though, it's completely fine if it still doesn't sit right for you and your team).

Example: Many objects can be an "EventDispatcher". For the sake of APIs, this must conform to an interface. But, you also want to provide a basic event dispatcher for delegation. DefaultEventDispatcher would be fine, but it's a bit long, and if you are going to be seeing the name of it often, you might prefer to use the base name EventDispatcher for the concrete class, and implement IEventDispatcher for custom implementations:

/* Option 1, traditional verbose naming: */
interface EventDispatcher { /* interface for all event dispatchers */ }
class DefaultEventDispatcher implements EventDispatcher {
  /* default event dispatcher */
}

/* Option 2, "I" abbreviation because "EventDispatcher" will be a common default: */
interface IEventDispatcher { /* interface for all event dispatchers */ }
class EventDispatcher implements IEventDispatcher {
  /* default event dispatcher. */
}

Answer 2

I decide the naming by the use case of the interface.

If the interface is used for decoupling, then I choose Impl for implementations.

If the purpose of the interface is behavioral abstraction, then the implementations are named according to what they are concretely doing. I often append the interface name to that. So if the interface is called Validator, I use FooValidator.

I find that Default is a very bad choice. First it pollutes code completion features, because the names always start with it. The other thing is that a default is subject to change over time. So what first might be a default can some time after be a deprecated feature. So either you always start renaming your classes as soon as defaults change or you live with misleading names.

Answer 3

I agree with Nicole's answer (particularly that the interface probably isn't necessary in most cases), but for the sake of discussion I'll throw out an additional alternative other than OrderImpl and DefaultOrder: hide the implementation behind a static factory method like Orders.create(). For example:

public final class Orders {
  public static Order create() {
    return new Order() {
      // Implementation goes here.
    };
  }
}

With this approach, the implementation could be an anonymous inner class, or it could be a private class with Default or Impl in the name, or it could be named something else entirely. Which ever choice is made, the caller doesn't need to care, so you get more flexibility now and later on when/if you decide to change it.

Some great examples of this pattern in practice are the java.util.Collections and java.util.concurrent.Executors utility classes, whose methods return hidden implementations. As Effective Java mentions (in Item 1), this pattern can help keep the "Conceptual weight" of the API smaller.

Answer 4

I always go for OrderImpl simply because it shows up alphabetically right after the Order interface.

Answer 5

I think that while Default can make sense in some cases, it would be more helpful to describe the implementation. So if your interface is UserProfileDAO then your implementations can be UserProfileSQLDAO or UserProfileLDAPDAO or something like that.

Answer 6

if possible, name it after what/how it does its thing.

usually worst approach is naming it after how it is supposed to be used.

If it is supposed to be used as base class for implementation, you can use BaseX or AbstractX (if it is abstract (but try to squeze in what it does, because if it did not do anything you would not create it, you already have interface). If it provides simplest possible functionality and it is expected to be used directly (not extending it) when such functionality suffices, you can call it SimpleX or BasicX.

If it is used unless some other implementation is provided, name it DefaultX

Answer 7

Try to figure out what is more concrete or specific about the class than the interface and incorporate that into the name.

Say you have an interface for persisting data, FooDao. Persistence could be to a flat file, an XML document, a spreadsheet, a relational database, a non-relational database, etc. If the class is persisting data to any SQL database, try FooSql implements FooDao.

If you have code specific to a relational database vendor, try FooMssql, FooOracle, or FooDb2. Or, maybe FooDaoMssql or FooDaoPostgre would suit your purposes better.

The point is, don't just add letters that only serve the purpose of creating a unique identifier; try to give the name something more meaningful. That has two good effects. It still communicates more meaning to the next developer, even if you have only one implementing class. Even if you start with only one implementing class, if you ever find yourself needing another implementation, you won't find yourself with names like ..Impl and ..Impl2, or ..Impl and ..Mongo.

Answer 8

You can name interface with prefix I (IWhatever) and then make implementation Whatever.

Official Java code conventions don't tell about this kind of naming for interfaces, however this kind of naming helps recognition and navigation.

Answer 9

Most of these answers describe what is being done but not why.

What has happened to OO principles? What does Impl tell me about a class and how to use it? You should be concerned about understanding the usages not how it is constructed.

If I create a Person interface, what is a PersonImpl? Meaningless. At least DefaultPerson tells me whoever coded it shouldn't have created an interface.

Interfaces are typing for polymorphism and should be used as such.