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?

9 Answers 9


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. */
  • 3
    +1 for solid answer. Like the reasoning behind not using Impl.
    – Gary
    May 12, 2011 at 20:35
  • 3
    +1 absolutely agree. Naming an interface away from the domain concept it represents is entirely missing the point.
    – rupjones
    May 12, 2011 at 22:10
  • 12
    "if you will only ever have one implementation", how do you know beforehand that you will only have one implementation ? "every interface has or may have two or more implementations"... before having two implementations, you first have none, the you have one, then you have two, I mean there can be a moment when you have only one implementation, just prior to implementing the second one. Jul 29, 2013 at 19:49
  • 3
    @NickC I'm not being pedantinc about semantics (I'm a poet and I didn't even know it). English is not my mother tongue so I cannot be pedantic about it. I was talking about flawed logic. You use interfaces for decoupling. That doesn't require a certain number of implementations. Jul 29, 2013 at 20:24
  • 5
    if you will only ever have one implementation, do away with the interface - unless you want to test the component in which case you might want to keep that interface in order to create MockOrder, OrderStub or similar. Feb 16, 2014 at 17:18

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.


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.

  • 1
    +1 for an interesting additional case: anonymous implementations.
    – Gary
    Jan 5, 2013 at 10:59
  • 2
    Also used extensively in Guava.
    – Nicole
    Jul 30, 2013 at 20:50

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

  • 2
    And how to do you handle the ongoing further implementations, for special handling and so on?
    – Gary
    May 12, 2011 at 20:14
  • 2
    You asked about the initial implementation. Once you start implementing DomesticOrder, ForeignOrder, or whatever, they are named more thoughtfully and without regard to their position in the alphabet. May 12, 2011 at 20:19
  • Quite right - I've edited the original question to reflect this new requirement.
    – Gary
    May 12, 2011 at 20:20
  • 1
    Not a good idea If there are going to be more that one implementation.
    – Sadegh
    Jul 3, 2017 at 19:27

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.


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.

  • Why would you prefix the interface with an I? Is it to aid recognition in navigation?
    – Gary
    May 12, 2011 at 20:19
  • @Gary: prefixing interface types with I is a well-established convention in the Delphi language. In Delphi class types are prefixed with T. So we would have an IOrder interface and a TOrder default implementation with TSomethingOrder and TBullMarketOrder as specific implementations. May 12, 2011 at 20:22
  • 3
    I've seen this convention used heavily in .NET development as well. Perhaps because Microsoft's documentation and examples use it. May 12, 2011 at 20:23
  • 5
    It appears that @Renesis has come up with a useful case for using it within Java. Personally, I'd rely on the IDE to tell me the difference otherwise we'd have E's for Enums, C's for classes and all largely redundant.
    – Gary
    May 12, 2011 at 20:51

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


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.


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.

  • 1
    The accepted answer from @NickC goes into some detail about what is being done and why.
    – Gary
    Nov 13, 2013 at 16:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.