0% found this document useful (0 votes)
108 views

Java Abstract Class Vs Interface Example Program

Interface is used when you only know the contract and not the implementation, such as when defining how different flight vendors provide flight and booking information. Abstract class is used when you know some implementation details but need to leave other details abstract for subclasses to implement, such as knowing how to check rules for SMS sending but leaving tower connection abstract for different telecom vendors to implement.

Uploaded by

Amol Adhangale
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
108 views

Java Abstract Class Vs Interface Example Program

Interface is used when you only know the contract and not the implementation, such as when defining how different flight vendors provide flight and booking information. Abstract class is used when you know some implementation details but need to leave other details abstract for subclasses to implement, such as knowing how to check rules for SMS sending but leaving tower connection abstract for different telecom vendors to implement.

Uploaded by

Amol Adhangale
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 13

When to use interface and abstract class in Java?

what is the difference between them?

interface Vs abstract class in Java.


Interface:
Interface is used when you want to define a contract and you
don't know anything about implementation. (here it is total
abstraction as you don't know anything.)
Abstract class:
Abstract class is used when you know something and rely on
others for what you don't know.(here it is partial abstraction as
some of the things you know and some you don't know.)
When to use Interface
Scenario,
Consider 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 "airasia", "british
airways" and "emirates".
2. Place and order for seat to respective vendor.
How should we design our application considering interfaces and abstract
class? In this scenario, interface is useful or abstract class?
Remember, In this application, we don't own any flight. we are just a
middle man/aggregator and our task is to first enquire "airasia", then
enquire "british airways" and at last enquire "emirates" 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 "airasia", "british airways" and "emirates" 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 "getAllAvailableFlights()"
"getAllAvailableFlights()" from "airasia" may have used SOAP service
to return list of flights.
"getAllAvailableFlights()" from "british airways" may have used REST
service to return list of flights.
"getAllAvailableFlights()" from "emirates" 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 "getAllAvailableFlights" that all the
flight vendor should provide and return list of flights.
2. Similarly, for booking I only care for method name "booking()" 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 "getAllAvailableFlights()" and "booking()"
method from them to run our aggregator service.
In this situation, Interface is useful because we are not aware
of the implementation of all the 2 methods required, and what
we know is the contract methods that vendor(implementer)
should provide. so due to this total abstraction and for defining
the contract, interface is useful in this place.
Technically, we need to design our interface somewhat like below,
FlightOpeartions.java(Contract)
public interface FlightOpeartions {
void getAllAvailableFlights();
void booking(BookingObject bookingObj);
}
BookingObject.java
public class BookingObject {}
BritishAirways.java (Vendor 1)
public class BritishAirways implements
FlightOpeartions {

public void getAllAvailableFlights(){


//get british airways flights in the
way
//they told us to fetch flight details.
}

public void booking(BookingObject flightDetails){


//place booking order in a way British
airways
//told us to place order for seat.
}

}
Emirates.java (Vendor 2)

public class Emirates implements FlightOpeartions


{

public void getAllAvailableFlights(){


//get Emirates flights in the way
//they told us to fetch flight details.
}

public void booking(BookingObject flightDetails){


//place booking order in a way Emirates
airways
//told us to place order for seat.
}
}
How Interface achieve Polymorphism.
Note:
Interface just speak about the contract capabilities and don't know
anything about implementation.
Example:
Interface can very well say that "I can get all available flights", "I can do
booking" because they have that capability, but they don't know "How
exactly to get all available flights", "How exactly to do booking" and this
is the job of class that accepted Interface contract in other words it is
the job of class that implements that interface.
Interface helps in achieving dynamic Polymorphism because it
focus only on capabilities and don't care about implementation
which implemented class MUST take care of as define in
interface contract.
Interface very well knows what methods it is capable of calling, and it is
sure that class that implements this interface definitely has given the
body to those methods, so it blindly calls
"interfaceReference.capableMethods()",
(in our example: flightOperationsReference.getAllAvailableFlights())
It doesn't care, what object has been assigned to "interfaceReference", (it
can be of any class that implemented it), but when interface calls
"interfaceReference.capableMethods()", "capableMethods()" method will
definitely be called on class whose object has been assigned to
"interfaceReference" and that is the contract that every implementer of
interface should provide body to methods defined in interface.
When to use Abstract class
Scenario,
Consider we want to start a service like Bulk SMS sender, where we take
orders from various telecom vendors like Airtel, France Telecom,
Vodafone etc.
For this, we don't have to setup your own infrastructure for sending SMS
like Mobile towers but we need to take care of government rules like
after 9PM, we should not send promotional SMS, we should also not send
SMS to users registered under Do Not Disturb(DND) service etc.
Remember, we need to take care of government rules for all the
countries where we are sending SMS.
Note: for infrastructure like towers, we will be relying on vendor who is
going to give us order.
Example, In case of,Vodafone request us for bulk messaging, in that case
we will use Vodafine towers to send SMS.
Airtel request us for bulk messaging, in that case we will use Airtel
towers to send SMS.
What our job is to manage Telecom Regulations for different countries
where we are sending SMS.
So what all methods we require would be somewhat like below,
public void eastablishConnectionWithYourTower(){
//connect using vendor way.
//we don't know how, candidate for abstract
method
}

public void sendSMS(){


eastablishConnectionWithYourTower();
checkForDND();
checkForTelecomRules();
//sending SMS to numbers...numbers.
destroyConnectionWithYourTower()
}

public void destroyConnectionWithYourTower(){


//disconnect using vendor way.
//we don't know how, candidate for abstract
method
}

public void checkForDND(){


//check for number present in DND.
}

public void checkForTelecomRules(){


//Check for telecom rules.
}
Out of above 5 methods,
1. Methods we know is "sendSMS()", "checkForDND()",
"checkForTelecomRules()".
2. Methods we don't know is "eastablishConnectionWithYourTower()",
"destroyConnectionWithYourTower()".
we know how to check government rules for sending SMS as that is what
our job is but we don't how to eastablish connection with tower and how
to destroy connection with tower because this is purely customer
specific, airtel has its own way, vodafone has its own way etc.
So in the given scenario, we know some methods but there also exist
some methods which are unknown and depends on customers.
In this case, what will be helpful, abstarct class or interface?
In this case, Abstract class will be helpful, because you know
partial things like "checkForDND()", "checkForTelecomRules()"
for sending sms to users but we don't know how to
eastablishConnectionWithTower() and
destroyConnectionWithTower() and need to depend on vendor
specific way to connect and destroy connection from their
towers.
Let's see how our class will look like,
abstract class SMSSender{

abstract public void


eastablishConnectionWithYourTower();

public void sendSMS(){


/*eastablishConnectionWithYourTower();
checkForDND();
checkForTelecomRules();

sending SMS to numbers...numbers.*/


}

abstract public void


destroyConnectionWithYourTower();

public void checkForDND(){


//check for number present in DND.
}
public void checkForTelecomRules(){
//Check for telecom rules
}
}

class Vodafone extends SMSSender{

@Override
public void eastablishConnectionWithYourTower() {
//connecting using Vodafone way
}

@Override
public void destroyConnectionWithYourTower() {
//destroying connection using Vodafone way
}
}

class Airtel extends SMSSender{

@Override
public void eastablishConnectionWithYourTower() {
//connecting using Airtel way
}

@Override
public void destroyConnectionWithYourTower() {
//destroying connection using Airtel way
}

}
So to summarize,
For Interface:
Interface is used when you don't know anything about
implementation but know the contract that implementer
should have to accomplish the task.
For Abstract class:
Abstract class is used when you know partial
implementation, where say out of 5 methods, you know
implementation of 3 methods and don't know
implemenatation of 2 methods in that case 2 methods will
be abstract and you need to rely on implementer as a
contract to must provide body of abstract methods to
accomplish the task.

You might also like