Interfaces and Implementations
February 16th, 2010
Consider a Java interface and class: Dog and DefaultDog. Which of these two conventions is best?
Option 1 : Dog
Name the interface Dog and call the implementation something like DefaultDog or DogImpl.
Option 2 : IDog
Name the interface IDog and call the implementation Dog, DefaultDog, or whatever else you can come up with.
The Answer
I prefer option 1 for these reasons:
- A vast majority of your code will utilize the interface, rather than the implementation. Thus, it’s best to keep the interface name clean, and reserve the weird names for the implementation classes, which you hardly ever see.
- Prefixing names with “I” feels like Hungarian notation. The name redundantly specifies what the
interfacekeyword already specifies. Should we also adopt notations for things that are static, final, abstract, etc? I think not. - Many interfaces will have multiple implementations. Thus, each implementation will need a different name. I see no need to also put some name discriminator on the interface.
Regarding names like “Impl” and “Default”, I prefer to avoid those when possible. For example, ArrayList and LinkedList are far better names than DefaultList or ListImpl.
Totally agreed! I would also like to mention that I try to add the part of the name that refers to the kind of implementation (like ArrayList or LinkedList) to the beginning of the name rather than to the end. I’ve seen too many classes called “ListUsingArray”…
i am with you. i give the simple, abstract-generalized name to the interface. i never liked IBlah and BlahImpl conventions.
How is prefixing interfaces with “I” Hungarian Notation and suffixing implementations with “Impl” is not? The Hungarian Notation aspect is a red herring.
Your approach would be fine if you could guarantee that all your concrete types will have a distinctive syntax (”Default”, “Impl”, whatever), but I bet that most of them don’t, so you can’t tell them from interfaces.
In short, your position is “I don’t care about differentiating interfaces from implementations when reading code”. Matter of taste I guess, but I do code reviews several times a day and a consistent convention is a life saver.
I’m guessing you don’t often review code that is not yours?
I also prefer 1. The additional ‘I’ is just polluting the name.
Also most ide will show you graphically if “foo.java” is an interface or a class or an enum or … (option 2 from above would probably require to name Enums ‘EFoo’ just in case ..)
I agree with you.
But I also have to say that this situation shouldn’t be very common. An interface describes a behavior, while a class describes an object. Hence, the interface’s name should be something like Barker, while the classes could be Dog, DefaultDog, or even Parrot.
Also, having a DogImpl class indicates that there shouldn’t be an interface in the first place. Its so damn easy to extract an interface from an existing class when you actually need it…
Follow the framework’s lead: Option 1 for java, option 2 for .NET code. You can’t avoid using framework code so going against the framework’s convention would lead to a weird style mix.
I do something similar when naming members. In .NET or java I wouldn’t even consider using underscores. In python I follow the PEP-8 convention which uses underscores all over the place. Again, follow the framework’s lead.
I miss option 3 where there is no “Impl” and no “IWhatever”. I am sure you will not need the whole dog in the client. Maybe only a “Pet” you can feed or any other role …. Reminds me of the “interface segregation principle”:
http://www.objectmentor.com/resources/articles/isp.pdf
Agreed!
Sebastian you’ve probably not used a framework like Spring, in which the convention is to code to an interface which you connect to a specific implementation (which may have eg alternate vendors ) in your app’s configuration. I think this underlies Eric’s points 1 and 3 above.
On the other hand, Eric I wonder if your notes about Hungarian notation might just be stylistic preference. I’ve used it a lot in the c/c++ world and it’s a really useful convention, only partially obviated by modern IDEs.
My thinking exactly.
No “I” in interfaces. Bob Martin explains in “Agile Software Development, Principles, Patterns, and Practices” that prefixing “I” leads to non-reusable interfaces, because the interfaces should be closer to its users (clients) then its providers (implementations).
Consider a Lamp class with switchOn() and switchOff() methods. When you extract an interface, should you call it “ILamp” ? No, you should call it “Switchable” !
In fact, Bob Martin has a whole chapter on naming in his newest book: Clean Code.
“How is prefixing interfaces with “I” Hungarian Notation and suffixing implementations with ‘Impl’ is not? The Hungarian Notation aspect is a red herring.
This red herring quacks like a straw man! I don’t see Eric saying must use *Impl, must not use I*.
“In short, your position is ‘I don’t care about differentiating interfaces from implementations when reading code’. Matter of taste I guess, but I do code reviews several times a day and a consistent convention is a life saver.
I’m guessing you don’t often review code that is not yours?
“”"
This is not a good enough reason to introduce noise anymore. I spend most time reading other people’s code these days and the answer was simple – highlight interfaces in your Java IDE settings. You’ll see concrete class easily, especially where they’re being new’d or passed in as arguments. If you’re reviewing patches, then apply them so they show up instead of just eyeballing changesets.
I guess the meta argument that interfaces are hobbled compared to constructs like Scala traits is for another day
The Suffix like Impl or Default does not say anything. I also try to avoid such constructions. But some time it’s very hard to imagine good prefix. When you develop application by interface a specially. In such frameworks like Spring very hard to say what prefix or suffix you should use. It is just nature of framework.
Ultimately the classname should be a short descriptive thing, appending “Impl” or using “I” as a prefix for an interface does not help. After all an interface is a description of something, prefixing with “I” or addng “Impl” does not say how we are implementing that interface.
Most of time one (should) works with interfaces, so it makes sense to have a simple name that describes the “what” and not the “how”. A prefix like “I” is just ugly, and becomes silly as good code will have a lot of interfaces. Using a compound naming system like implementation detail + interface name is descriptive. ArrayList and LinkList are perfect examples of this, each describing “what” type of “List’ they are.