Question: After reading [Should package names be singular or plural?](https://softwareengineering.stackexchange.com/q/75919/7167) 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: 
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](https://softwareengineering.stackexchange.com/questions/75956/default-vs-impl-when-implementing-interfaces-in-java/75958#75958) 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. */
}

```
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