4 Abstract classes versus interfaces

In Java, there is no abstract class. Instead there are interfaces instead.

An interface is “kind of” like an abtract method that it defines interfaces to be implemented. However, an interface also has the additional restrictions that

• There can be no concrete methods. In other words, all methods must be abstract, and to be implemented.
• There can be no data members.

So, what is the big deal? C++ abstract classes are more flexible, therefere it is better!

Well, considering Java was created after C++, the deliberate choice to use interface instead of general (and flexible) abstract class has its reasons.

Conceptually, an interface is not a superclass. A class is known to implement an interface, not to inherit from it. In other words, the relationship between a class and an interface is not no longer a “is a” relationship. Instead it is a “a portal to” relationship.

Let us consider an example in listing 5.

In this case, DriversView is a pure abstract class, which means it has all the properties of an interface. Note that a Car is not a DriversView. Instead, a DriversView is a portal to access a Car. This is a fundamental change of how we look at things!

Obviously, it only makes sense that we also provide additional interfaces like PassengersView, RearPassengersView and etc. C++ has multiple inheritance, it is not a problem. Java does not have multiple inheritance, but a class can implement multiple interfaces, so there is no problem, either.

But, it is still not clear how this “a portal of” view has any advantage. The advantage is difficult to realize in most programs that are compiled, linked and executed as monolithic programs.

However, when components of a program can spread out as individual processes that may run on different hosts, then the “a portal of” interface starts to make sense.

An object of Car class may be created on host H1. However, a programming running on host H2 may want to “drive” the Car object. On host H1, a Car object adds its interface to a registry of all interfaces to all objects running on H1. When the client program on host H2 makes a request to access the Car object (by handle, not reference or pointer), the interface is looked up, and remote procedure calls (RPCs) are performed. Note that all Car object related operations are performed on H2.

This explains why concrete methods and data members are not desirable. Even though the interface of a Car object is exposed to the client program running on host H2, the state of the Car object resides on host H1. As a result, the client program has no physical access to the state of the Car object even if the data members are public.

The same argument applies to concrete methods. Because the code to operate on the Car object also resides on host H1, it serves no purpose to expose the implementation of any methods to the client program running on host H2.