When to use Interface in java with example

When to use Interface in java with example?

---

Interface is used in a situation,

1. When you know the contract methods but don't know anything about the implementation.
2. Your contract implementation can change in future.
3. You want to achieve dynamic polymorphishm and loose coupling that is by just changing one line of code, you should be able to switch between contract implementer.

Lets understand above points in more details:

Interface in Java.

---

When to use Interface and Abstract class with Real example: 
https://javabypatel.blogspot.com/2017/07/when-to-use-abstract-class-and-interface-difference-between-them.html

When you know the contract methods but don't know anything about the implementation

Lets say we want to start a service like "makemytrip.com" or "expedia.com",  where we are responsible for displaying the flights from various flight service company and place an order from customer. 
Lets keep our service as simple as, 

1. Displaying flights available from vendors like "AirIndia", "Emirates" and "JetAirways".
2. Place and order for seat to respective vendor.

Remember, In this application, we don't own any flight. we are just a middle man/aggregator and our task is to first enquire "AirIndia", then enquire "Emirates" and at last enquire "JetAirways" about the list of flights available and later if customer opts for booking then inform the respective flight vendor to do booking.


For this, first we need to tell "AirIndia", "Emirates" and "JetAirways" to give us list of flights, internally how they are giving the list that we don't care.

1. This means I only care for method name "getAllFlights()"
   
   "getAllFlights()" from "AirIndia" may have used SOAP service to return list of flights.
   "getAllFlights()" from "Emirates" may have used REST service to return list of flights.
   "getAllFlights()" from "JetAirways" may have used CORBA service to return list of flights.
   
   but we don't care how it is internally implemented and what we care is the contract method "getAllFlights" that all the flight vendor should provide and return list of flights.
   


2. Similarly, for booking I only care for method name "doBooking()" that all vendors should have, internally how this vendors are doing booking that I don't care.

To conclude: We know contract.

So we can say that we know the contract that irrespective of who the Flight vendor is, you need "getAllFlights()" and "doBooking()" method from them to run our aggregator service.

Your contract implementation can change in future. 

Say we want to develop some business application which require usage of Database and we choose to use Oracle. So we will design something like below,

We are using Oracle database and all our layers are binded to use OracleDatabaseManager to fetch data using Oracle database.

Now, say tomorrow we plan to change our database to Postgresql, We will end up changing all our layers, which is wrong. If we need to change all our layers, imagine testing and development efforts required. 

So how our design should be which can sustain future changes ? Interface will come to rescue.
Instead of using calling concrete implementation menthods in service layer, we should call contract methods of interface which doesn't know anything about implementation.

In this appraoch, Service layer doesn't care as which implementation we are using.
So in future if we switch from Oracle to PostgreSQL or to any vendor, Service layer will have no impact and it will remain as it is because it calls interface contract methods which doesn't care about implementation.

Only change required is in Database layer which is also a minimal change.
Also, this design helps us adding more vendor as an when required without disturbing the existing vendor implementation.


You want to achieve dynamic polymorphishm and loose coupling that is by just changing one line of code, you should be able to switch between contract implementer.

From above point, you can see, by only changing the middle layer, we are able to switch database implementation to different vendor without disturbing service layer.

So we can say that our application or our service layer is not tightly coupled with database layer instead both layer works on contract which make them loosely coupled and changes on one layer doesn't affect another layer as contract still remains same.

You may also like to see

---

Interface example in Java with Program

Interface Vs Abstract class in Java OOPS.

Top Java Interface Interview Questions and Answers

When to use interface and abstract class in Java? what is the difference between them?

Java Multithreading and Concurrency Interview Questions and Answers with Example

Advanced Multithreading Interview Questions In Java

How ConcurrentHashMap works and ConcurrentHashMap interview questions.

Enjoy !!!! 

If you find any issue in post or face any error while implementing, Please comment.