Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

9 Answers 9

up vote 22 down vote accepted

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. */
}
share|improve this answer
1  
+1 for solid answer. Like the reasoning behind not using Impl. –  Gary Rowe May 12 '11 at 20:35
1  
Thanks. I updated with my thoughts on "I", since it's frequently seen in practice -- hope it doesn't change your mind on the +1 :) –  NickC May 12 '11 at 20:39
1  
Thanks for the update. Interesting case for the I prefix. –  Gary Rowe May 12 '11 at 20:46
2  
+1 absolutely agree. Naming an interface away from the domain concept it represents is entirely missing the point. –  rupjones May 12 '11 at 22:10
1  
"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. –  user61852 Jul 29 '13 at 19:49

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.

share|improve this answer

I agree with NickC'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.

share|improve this answer
    
+1 for an interesting additional case: anonymous implementations. –  Gary Rowe Jan 5 '13 at 10:59
1  
Also used extensively in Guava. –  NickC Jul 30 '13 at 20:50

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.

share|improve this answer
    
Why would you prefix the interface with an I? Is it to aid recognition in navigation? –  Gary Rowe May 12 '11 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. –  Marjan Venema May 12 '11 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. –  Ben Hoffstein May 12 '11 at 20:23
4  
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 Rowe May 12 '11 at 20:51

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.

share|improve this answer

Sometimes, there are good reasons for creating an interface where there is only a single concrete implementation. If your Java classes are very "tight" -- very final -- then mocking them with EasyMock or Mockito is difficult or impossible. You must resort to Powermock, which is a whole other ball of wax. I am not an expert on testing, but those more experienced around me try to avoid using Powermock.

If you have an interface that is faithfully implemented by your only concrete implementation, then mocking is with EasyMock or Mockito is trivial.

Finally, recently I discovered an interesting pattern that is used by the new JSON library for JavaEE called javax.json. The class Json provides static helpers to create concrete instances, but interfaces are used everwhere. All return types are interfaces. All said, this may not be possible to follow in legacy projects, so have some flexibility in your thinking.

share|improve this answer
    
You may have misread the question. This thread is about a naming strategy for interfaces not a mocking strategy. –  Gary Rowe Feb 18 at 10:28

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

share|improve this answer
1  
And how to do you handle the ongoing further implementations, for special handling and so on? –  Gary Rowe May 12 '11 at 20:14
    
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. –  Ben Hoffstein May 12 '11 at 20:19
    
Quite right - I've edited the original question to reflect this new requirement. –  Gary Rowe May 12 '11 at 20:20

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

share|improve this answer

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.

share|improve this answer
1  
The accepted answer from @NickC goes into some detail about what is being done and why. –  Gary Rowe Nov 13 '13 at 16:32

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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