Interface Naming in Java

Interface naming in Java

I prefer not to use a prefix on interfaces:

The prefix hurts readability.
Using interfaces in clients is the standard best way to program, so interfaces names should be as short and pleasant as possible. Implementing classes should be uglier to discourage their use.
When changing from an abstract class to an interface a coding convention with prefix I implies renaming all the occurrences of the class --- not good!

Java Interfaces/Implementation naming convention

Name your Interface what it is. Truck. Not ITruck because it isn't an ITruck it is a Truck.

An Interface in Java is a Type. Then you have DumpTruck, TransferTruck, WreckerTruck, CementTruck, etc that implements Truck.

When you are using the Interface in place of a sub-class you just cast it to Truck. As in List<Truck>. Putting I in front is just Hungarian style notation tautology that adds nothing but more stuff to type to your code.

All modern Java IDE's mark Interfaces and Implementations and what not without this silly notation. Don't call it TruckClass that is tautology just as bad as the IInterface tautology.

If it is an implementation it is a class. The only real exception to this rule, and there are always exceptions, could be something like AbstractTruck. Since only the sub-classes will ever see this and you should never cast to an Abstract class it does add some information that the class is abstract and to how it should be used. You could still come up with a better name than AbstractTruck and use BaseTruck or DefaultTruck instead since the abstract is in the definition. But since Abstract classes should never be part of any public facing interface I believe it is an acceptable exception to the rule. Making the constructors protected goes a long way to crossing this divide.

And the Impl suffix is just more noise as well. More tautology. Anything that isn't an interface is an implementation, even abstract classes which are partial implementations. Are you going to put that silly Impl suffix on every name of every Class?

The Interface is a contract on what the public methods and properties have to support, it is also Type information as well. Everything that implements Truck is a Type of Truck.

Look to the Java standard library itself. Do you see IList, ArrayListImpl, LinkedListImpl? No, you see List and ArrayList, and LinkedList. Here is a nice article about this exact question. Any of these silly prefix/suffix naming conventions all violate the DRY principle as well.

Also, if you find yourself adding DTO, JDO, BEAN or other silly repetitive suffixes to objects then they probably belong in a package instead of all those suffixes. Properly packaged namespaces are self documenting and reduce all the useless redundant information in these really poorly conceived proprietary naming schemes that most places don't even internally adhere to in a consistent manner.

If all you can come up with to make your Class name unique is suffixing it with Impl, then you need to rethink having an Interface at all. So when you have a situation where you have an Interface and a single Implementation that is not uniquely specialized from the Interface you probably don't need the Interface in most cases.

However, in general for maintainability, testability, mocking, it's best practice to provide interfaces. See this answer for more details.

Also Refer this interesting article by Martin Fowler on this topic of InterfaceImplementationPair

What is standard for Interface naming in java api

It's very common for those '-able' names to be interfaces in Java, but there is no official convention for interface naming that I've found that suggests that '-able' names should be interface names, though typically that is the case.

Official Java naming conventions can be found here - it's pretty lean, there really aren't any restrictions for class or interface naming:

http://www.oracle.com/technetwork/java/codeconventions-135099.html#367

As to your Throwable question, James Gosling once answered why it's a class rather than an interface, even though the name was more fitting for an interface.

Unfortunately, the original article from Sun/Oracle's site has vanished into the internet ether, so I can only provide indirect attribution:

http://c2.com/cgi/wiki?JavaExceptionQuestion
http://www.ibm.com/developerworks/forums/thread.jspa?threadID=58994&tstart=45

edit: Since I continue to get upvotes to this question, I found the link to the Sun discussion via the Wayback Machine, here: http://web.archive.org/web/20071013225816/http://java.sun.com/features/2002/03/gosling.html?source=jdc_news&date=20020430

JDC: Why is Throwable not an interface? The name kind of suggests it should have been. Being able to catch for types, that is, something like try{}catch (), instead of only classes. That would make the Java programming language much more flexible.
JG: The reason that the Throwable and the rest of those guys are not interfaces is because we decided, or I decided fairly early on. I decided that I wanted to have some state associated with every exception that gets thrown. And you can't do that with interfaces; you can only do that with classes. The state that's there is basically standard. There's a message, there's a snapshot, stuff like that that's always there. and also, if you make Throwable an interface the temptation is to assign, to make any old object be a Throwable thing. It feels stylistically that throwing general objects is probably a bad idea, that the things you want to throw really ought to be things that are intended to be exceptions that really capture the nature of the exception and what went on. They're not just general data structures.

Java Interface Naming Conventions

There's no "one" correct answer here. Naming is quite subjective but what matters the most is that it should be consistent throughout the code base. I would just like to add (to @fge's answer) some more options for you:

Making the Interfaces more generic.

EmployeeRepository implements Repository
DocumentMappingService implements MappingService

Calling your single implementations "defaults".

DefaultEmployeeRepository implements EmployeeRepository
DefaultDocumentMappingService implements DocumentMappingService

Calling your base implementations (if, sometimes extended) as "support".

EmployeeRepositorySupport implements EmployeeRepository
DocumentMappingServiceSupport implements DocumentMappingService

I come across these naming conventions a lot when using the Spring Framework.

Edit : In response to user nyxz's comment about the -Base or Base- convention.

Like I said before, naming is subjective and there's nothing wrong with using the Base nomenclature as such. But, personally, I don't prefer using it. Here's why:

If your implementations would mostly be used directly, then the code instantiating the classes leaves an impression of breaking the OOP hierarchy. That perhaps a specific derived class should have been instantiated.
If your implementations would mostly be extended from, then the word Base becomes redundant in a way. You're extending from it so, of course, it's a base class. Duh!

The 2nd point mostly applies to peripheral classes in your project. Extension points that you provide when you're publishing a framework or library to be used and extended in other projects.

On the other hand, a good use case for using the Base terminology would be for classes internal to your framework that factor common functionality out of other peripheral classes. Since, these classes aren't supposed to be instantiated directly, they are marked abstract, which is in line with the 1st point.

Here's the Adapter hierarchy from the Android framework as an example:

Interface hierarchy.

public interface Adapter
public interface ListAdapter extends Adapter
public interface SpinnerAdapter extends Adapter

The abstract Base class that factors out the common behaviour and interface implementations.
```
public abstract class BaseAdapter implements ListAdapter, SpinnerAdapter
```

Peripheral classes that are mostly instantiated but sometimes extended by an Android application.

public class SimpleAdapter extends BaseAdapter implements Filterable
public class ArrayAdapter<T> extends BaseAdapter implements Filterable

Java - interface methods naming convention

There are no conventions for naming methods specifically declared in an interface.

Interface methods should follow the same conventions for naming methods, which recommend verbs/actions camel-case method names.

Although get may seem redundant in getDefinition(), it's still a better method name compared to definition(), in light of the "verbs" convention.

One isn't limited to the get prefix for all value-returning methods (there are many examples of interfaces with no getXYZ methods in the JDK). Where the meaning is appropriate, it's common to see methods like createJsonParser, fetchDefinition, etc.

But in my opnion, TableProvider<T> and ServiceProxy<T> don't seem to lend themselves to a very intuitive, common name for the method getServiceProxy. This is why these guidelines are just conventions, something that you or your team can decide not to follow in some cases.

Java interface naming convention

A main(String[] args) method has nothing to do with the naming of the class and it's filename.

In fact, the file containing your code has to be identical with the name of the (top-level) class inside that file.

Java Interface, AbstractClass and Enum naming convention

In Java: Foo, AbstractFoo and Foo - although AbstractFoo could just be Foo.

Evidence:

java.util.List (interface)
java.util.AbstractList (abstract class)
java.util.Formatter.BigDecimalLayoutForm (enum)

For the interface part, see the Naming Conventions section of the Java Coding Conventions document. It doesn't talk about enums and abstract classes though.

Interface Naming in Java