Should we need to differentiate between Interface class and abstract class, in terms of naming convention?

Question

Hi,

Is that important to differentiate between Abstract class and interface class?

Abstract class is merely an interface class, with some concrete methods.

If the abstract class shares the same prefix "I" with Interface class, we can easily upgrade our interface class to abstract class, by introducing new logic etc.

UPDATE

The reason why I am asking this is, interface impose some limitation when the project grows. For instance,

If one interface has been "implemented" by thousand classes, and at some point we need to introduce a few new methods in the base class, we will have to fix all the sub classes.

Abstract class provides flexibility in terms of functional expansion, as it can provide default implementation without affecting sub classes.

That's why I got the idea of using interface and abstract class interchangebly.

ICar car = new Merz(); // ICar can be interface or abstract class

However, when i think about it again, we still have to change all the sub classes, due to the fact that the class declaration forces us to use "extends" or "implements" at the very beginning.

So I think there is no option for doing polymorphism on abstract/interface class.

Answer 1

An "I" prefix isn't really the Java way. That's more C#.

For Java, I generally use this convention:

• Interface: Builder
• Abstract Class: AbstractBuilder
• Concrete Class: BuilderImpl, DefaultBuilder, MyBuilder, etc

I think that agrees fairly well with Java standards (Map, AbstractMap, HashMap respectively).

As for replacing interfaces with abstract classes, that requires a refactor. I think it's a better idea to use interfaces for all method returns, data member types, local variable types and parameters. Abstract classes are (or should be) an implementation detail.

Going back to the Map example, that means everything is a Map. You can create your own Map subclass. The JDK provides you a helper class that does most of the boilerplate. If you declared members in terms of the abstract class, you'd be forced to use it and that isn't the best outcome.

Answer 2

No, you can't do that easily because you may be also inheriting from another class, and Java doesn't allow multiple inheritance from classes.

It is better to have a standard naming structure. In Java, I'm not sure you need to adopt the I prefix; I think it is the able suffix. Either way, adopt one, and make it consistent.

-- Edit

With abstract classes, my preference is for a Base suffix, but to each his own :)

Answer 3

An abstract class is very different from an interface on one particular thing.

A given class can implement any number of interfaces, but only extend one abstract class.

Hence, they should be treated very differently, but not in naming terms. Choose a short, descriptive name for the interfaces - you will see it a LOT again. For instance List is an interface, but ArrayList is the class.

Answer 4

I am working with Java the hole day and my colleagues and i are using

• Interface : IDialog
• Abstract: AbstractDialog
• Class: DefaultDialog, WarningDialog

Abstract classes implements most common interface methods or most used util methods.

You do not have to extend from the Abstract class. You should extend from the Abstract class, if the implemented methods are usefull for the class you want to generated.

Otherwise you should implement the interface and implement the methods again.

You extend from 1 class only, so it makes no sence when you extend from the Abstract class if you only can use 50% of the methods.

Answer 5

Interfaces in Java end in 'able'. For Ex: Cloneable,Serialisable. So if possible you can choose a name that ends with 'able'. An abstract class which implements an interface should start with name 'abstract'. for ex: abstractLinkedList. The concrete class are not subjected to any such naming convention other than that they should make sense and start with a capital letter. I would suggest you to choose interface name that ends with 'able' or you can prefix I (last resort, not recommended for java but the default naming convention in MS languages like c#) to differeniate your interface from class implementation

Answer 6

@ janetSmith, well you can stick to cletus answer to use Car as interface name and CarImpl as the class that implements car interface. The only problem is a cursory look at 'Car' doesnt indicate whether it is an interface or a class unless one also looks at CarImpl. If you want, you can stick to prefixing interface names with 'I'. Its a trivial violation. Java practices suggests that. you can check it out here Interface names should end with able when the class that implements it exhibits that behaviour.For Ex: if a sub class of car provided behaviour like move, park,etc. you can have interface names like moveable, parkable. this applies for interface names that are verbs without the suffix 'able'.

--EDIT : My opinion go for ICar.