Teaching (Java) interfaces

Background

The motivation behind this article is that many people struggle with the (Java) Interface concept in university. The what is really simple, straightforward and understandable, but the why eludes many people. This was the case with me. It took many years before I realized the power of interfaces and how to properly benefit from them- I finally understood the why.

In his book, Clean Architecture, Robert C. Martin pointed out that using Plane and Car or Dog as a polymorphism example, is not the best way to communicate the concepts behind it, since the nature of interfaces in OOP is directed towards "plugin architecture".

Current Examples

To back up my claim, I googled for interface examples from (Estonian) universities and one example from depths of the internet.

• One example suggests that we can have interface Animal and then Dog and Cat implement this interface (so both have eat() and sleep() methods) (https://ained.ttu.ee/javadoc/Abstraction.html);
• The other example describes interfaces as follows: interface Callable with method call() is implemented by Client. There is also an AnotherClient who also implements the Callable interface so one can call call() on Client and AnotherClient (https://courses.cs.ut.ee/2014/OOP/fall/Main/Practice6);
• The example from the depths of the internet is interface Playable with method play(). Then TicTacToe implements the play() method (https://www.dummies.com/programming/java/what-is-an-interface-in-java/). To make things more clear, there is also a CardGame interface that HeartGame implements.

These examples show well how one can use an Interface in Java but I can bet that 99.9% of developers never use interfaces in such context. So the question is, how to teach interfaces better?

Another approach

I believe that the answer is in the why not in the what. For example, in object oriented languages, one main use case for interfaces is Dependency Inversion. This is also backed with Liskov substitution principle (LSP). The latter states that if class A and B both derive from C, then we can safely substitute A with B in the system without the knowledge of the using class.

So to use the concepts from the previous examples, we should be able to switch TicTacToe with HeartsGame without the player noticing. Since this is not how one would use LSP, let’s try a real example.

Example 1

Let's say that we have a class Service that processes some information from a data source. The IAdapter is an interface with method read(). We know that the system we are developing will eventually read data from a system through COM port but we do not have the device nor the implementation for the data source ready at the moment. Thanks to LSP, we can create a MockAdapter that implements IAdapter which returns some mock data, so we can start to develop our service class. When the device becomes available, we can develop ComAdapter. Since they both implement IAdapter, given that LSP actually works, we can substitute MockAdapter with ComAdapter without the service noticing the difference! This is the true beauty of LSP.

Example 2

The Dependency Inversion (DI) is somewhat more complicated principle but it would be impossible without interfaces. The DI states that the higher level logic should not depend on the lower level logic (e.g. the controller class shouldn’t depend on the service class) but vice versa. What this means in practice is that the controller package should contain an interface that describes the service that the controller uses. The controller depends on the interface and the service implements this interface thus inversing the dependency.

With no dependencies to concrete classes, the system is open for extendability. Combining our last two examples, if the device we accessed through COM port receives a hardware update so that the access is now over USB, we can write a UsbAdapter and the service that we wrote earlier, will be unmodified. If we hadn’t used interface, the service would have depended directly on the ComAdapter and the modification to the hardware side would have affected also our service!

The analogy with real life would be power adapters and cables. Recently I have seen adapters that have replaceable connectors for different countries. Regarding the adapter on the picture on the right, the connector could be USB but most probably the current and the voltage required by the consumer is not compatible with the current and voltage from an USB socket.

What is your take on this? Does this approach seem more feasible or you’d stick with Dog example? How do you help junior developers understand the concept of interfaces?