When to use Interface in java with example?
Interface is used in a situation,
- When you know the contract methods but don't know anything about the implementation.
- Your contract implementation can change in future.
- 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.
Interface in Java.
When to use Interface and Abstract class with Real example:
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,
- Displaying flights available from vendors like "AirIndia", "Emirates" and "JetAirways".
- Place and order for seat to respective vendor.
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.
- 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.
- 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.
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
If you find any issue in post or face any error while implementing, Please comment.