When should I use an interface in java? [closed]

A good example of when exactly to use interfaces specifically in Java would be ideal and any specific rulings that apply.

Solution 1:

A good place to look at would be the collections framework.

java.util.List //interface

java.util.ArrayList //Concrete class
java.util.LinkedList //Concrete class

So you can write code like this:

List l = new ArrayList();

l.add(..)
//do something else.

If in future you want to change the implementation with say LinkedList or you own AwesomeList which implements List interface, all you have to do is change the very first line to:

List l = new MyAwesomeList();
or
List l = new LinkedList();

The rest of the code would follow through.

Solution 2:

Use interfaces to define an application programming contract (blueprint, interface) which "3rd-party" vendors have to fully adhere and implement. This way the endusers can just code against the API contract and easily switch of the concrete implementation "under the hoods" without changing the code.

The JDBC API is an excellent example. It exist of almost only interfaces. The concrete implementations are provided as "JDBC drivers". This enables you to write all the JDBC code independent of the database (DB) vendor. You can just change the JDBC driver without changing any line of Java code (except of any hardcoded DB-specific SQL code) whenever you'd like to switch of DB vendor.

Another example is the Java EE API, it also contains pretty much interfaces and abstract classes. The concrete implementations are provided as "Java EE application servers", "Servletcontainers", etc, such as Sun Glassfish, Apache Tomcat, etc. This enables you to deploy the webapplication (WAR) to whatever Java web server you like.

Solution 3:

Interfaces are needed where you expect volatility in your program, points at which you anticipate change, points where your design needs to bend.

Implementation is fragile in this sense: it breaks quite easily. This is why subclassing isn't always the best solution, just as long-winded methods that implement some complicated behavior all by themselves are generally a bad idea.

Interfaces are more flexible and can deal with a lot more stress on the design of your program than implementation.

By introducing interfaces into your program, you really introduce points of variation at which you can plug in different implementations for that interface. Interfaces' primary purpose is abstraction, decoupling the "what" from the "how".

One important rule to keep in mind for safely doing so is the Liskov Substitution Principle [UncleBob, Wikipedia]. While a compiler in a language like Java will make sure that syntactically everything is in order (right number of parameters, types, ...), LSP deals with the semantics. In short, LSP says that every implementation of an interface must (also) behave itself correctly to be truly substitutable as described above.

Solution 4:

From oracle documentation page

Consider using interfaces if :

1. You expect that unrelated classes would implement your interface. For example,many unrelated objects can implement Serializable interface.
2. You want to specify the behaviour of a particular data type, but not concerned about who implements its behaviour.
3. You want to take advantage of multiple inheritance of type.

Have a look at related SE questions with code examples which have good answers already.

Is there more to an interface than having the correct methods

What is the difference between an interface and abstract class?

How should I have explained the difference between an Interface and an Abstract class?