Should we differentiate between an interface class and an abstract class, in terms of the naming convention?
Is it important to distinguish between abstract class and interface class?
An abstract class is just an interface class with some concrete methods.
If the abstract class has the same "I" prefix with the Interface class, we can easily update our interface class to the abstract class by introducing new logic, etc.
UPDATE
The reason I am asking this is because the interface imposes some constraints as the project grows. For example,
If one interface has been "implemented" by thousands of classes, and at some point we need to introduce several new methods into the base class, we will have to fix all the subclasses.
An abstract class provides flexibility in terms of functional extension because it can provide a default implementation without affecting subclasses.
This is why I got the idea of using an interface and an abstract interchangebly class.
ICar car = new Merz(); // ICar can be interface or abstract class
However, when I think about it again, we still have to change all subclasses because the class declaration forces us to use "extends" or "implements" at the very beginning.
So, I think there is no option for polymorphism in an abstract / interface class.
source to share
The "I" prefix is not really the Java way. It's more C #.
For Java, I usually use this convention:
- Interface Builder
- Abstract class: AbstractBuilder
- Concrete class: BuilderImpl, DefaultBuilder, MyBuilder, etc.
I think it fits well with Java standards (Map, AbstractMap, HashMap respectively).
As for replacing interfaces with abstract classes that require refactoring. I find it better to use interfaces for all method returns, item types, local variable types and parameters. Abstract classes are (or should be) an implementation detail.
Going back to the card example, that means it's all a card. You can create your own Map subclass. The JDK provides you with a helper class that does most of the boilerplate. If you declared members in terms of an abstract class, you would be forced to use it, and this is not the best result.
source to share
No, you cannot do this easily because you can also inherit from another class and Java does not allow multiple inheritance from classes.
Better to have a standard naming structure. In Java, I'm not sure if you need to accept the prefix I
; I think it is a suffix able
. Either way, take one and make it consistent.
- Change
With abstract classes I prefer the suffix Base
, but each one has its own :)
source to share
An abstract class is very different from an interface in one particular thing.
A given class can implement any number of interfaces, but only extend one abstract class.
Therefore, they should be treated quite differently, but not with naming. Choose a short descriptive name for the interfaces - you'll see it again. For example, List is an interface, but ArrayList is a class.
source to share
I work with Java on the day of the hole and my colleagues and I use
- Interface: IDialog
- Abstract: AbstractDialog
- Class: DefaultDialog, WarningDialog
Abstract classes implement the most common interface methods or the most commonly used usage methods.
You don't need to stand out from the Abstract class. You should migrate from the Abstract class if the inline methods are useful for the class you want to generate.
Otherwise, you must implement the interface and implement the methods again.
You only extend from 1 class, so there is no problem extending from Abstract class if you can only use 50% of the methods.
source to share
Java interfaces end in 'able'. For Ex: Cloneable, Serialisable. Therefore, if possible, you can choose a name that ends in "capable". An abstract class that implements an interface must begin with the name 'abstract'. for example: abstractLinkedList. The concrete class is not subject to any such naming, except that they must make sense and begin with an uppercase letter. I would suggest you choose an interface name that ends with "capable", or you can prefix i (the latter, not recommended for java, but the default naming convention in MS languages like C #) to delimit your interface from the class implementation
source to share
@janetSmith ok you can stick with cletus to use Car as the interface name and CarImpl as the class that implements the car interface. The only problem is that a quick look at "Car" does not indicate if it is an interface or a class, if you do not look at CarImpl. If you want, you can stick to prefix interface names with "I". This is a trivial violation. Java practice suggests that. you can check it here Interface names must end when the class that implements it exhibits this behavior. For Ex: If a subclass of a car class provides behaviors such as moving, park, etc. you can have interface names like movable, park. this refers to interface names that are verbs without the "capable" suffix.
- EDIT: My opinion for Icarus.
source to share