There are three important constructs in Java — concrete classes, abstract classes and interfaces. An abstract class is a special type of a class that is marked with the abstract keyword to indicate that the class cannot be instantiated but can be inherited if need be. An interface is actually a purely abstract class. We will explore more on both of these as we progress through this article. This article presents a discussion on when and how to use abstract class and interface when working with enterprise applications in Java.
What are Abstract Classes and Interfaces?
An interface doesn't have any state or implementation. It just can have the declaration of methods (method signature). An abstract class on the other hand can have both concrete and non-concrete methods. While an interface is type-centric, a class is implementation-centric. Unlike an interface, an abstract class can optionally have method implementations. An interface cannot have any implementation of the operations it declares. In essence, while an abstract class may or may not have an abstract method, you cannot have any implementation of the operations declared in an interface. An interface cannot have any data members — it can just have declaration of operations. So, an interface just defines a type and a set of operations on that type sans any implementation details. When you create a class that implements an interface, you should define those implementations explicitly.
Choosing between an abstract class and an interface in your designs
The choice between an abstract class and an interface in your design depends on many factors — it is not an either/or proposition. If you would like to design for change, i.e., you would like to design your application such that it can be changed when need be seamlessly, I'd prefer an interface over an abstract class. An interface is a good choice when frequent change in your design is inevitable. An abstract class may be a good choice when you are designing a framework and you would like to have some default operations in your abstract base class. Since Java allows you to implement multiple interfaces but extend just one class, an interface is also helpful when you would typically want to design your class that can implement multiple types.
Another point to consider to choose an interface over an abstract class is the amount of functionality that can be determined upfront and will not change over time. Keeping all such considerations in mind is essential to design applications that can scale and are high performant. The section that follows presents an overview of the points (the choice between abstract class and interface) you should consider when designing enterprise application.
Which one should I opt for when working on Enterprise Applications?
Now, let's discuss some interesting points that are related to using abstract classes and interfaces in enterprise applications. Should I use an abstract class or an interface when designing an enterprise application? Which one is better to use in terms of performance, maintenance and scalability?
I would strongly recommend using interfaces over abstract classes. Also, I prefer composition over inheritance. You should be aware of the fact that interfaces are much simpler to use and are very flexible. Interfaces are also preferred for testability. If you have a collaborator that is declared as an interface, it is easier to test as it can be mocked easily. On the contrary, collaborators that have been declared as an abstract type may be difficult to test and maintain if they contain initialization logic in them.
I would like to point here that Java 8 introduces default methods or defender methods that can be used to add new methods to interfaces without breaking the existing implementation. This is a great new feature that enables you to have an interface that contains a default implementation when one or more classes that implement that interface doesn't have implementation for such operation. Again, given a choice between an abstract class and an interface, I would always put my two cents on the latter for more ways than one.