I'm a beginner of Java.I have used abstract classes and interfaces.I
am not able to understand the exact usage of abstract classes.Where
the abstact classes are used in real-time environment?And what is the
difference between interfaces and abstact classes?
You can extend only one abstract class, but implement several
interfaces, with a single class.
You can put implementation code for some methods in an abstract class,
but not in an interface.
Interfaces define purely abstract data types (ADTs). Use them when
there might be many very different types with a common behavior and
capability.
Abstract classes can provide a skeleton implementation, or even
everything except one method that lets subclasses supply algorithms
with varying performance characteristics or whatnot (a form of
strategy pattern). If you want an implementation for some stuff,
provide an abstract class, or have an interface AND an abstract class
implementing it that provides a useful starting point for the
likeliest implementations.
Abstract classes are also useful if you specifically don't want
implementations to have some freedoms. For instance, you want a type
BankAccount but you don't want any that can go into overdraft without
a credit check. A BankAccount interface lets anyone make an
implementation, even one that lets the balance go negative without a
credit check. So you use an abstract class:
public abstract BankAccount () {
private int balance;
private boolean hadCreditCheck = false
private boolean creditCheckOK;
public final boolean withdraw (int amount) {
if (!checkWithdrawal(balance - amount, amount)) return false;
if (balance - amount < 0 && !passedCreditCheck()) return
false;
balance -= amount;
doWithdrawExtra(balance, amount);
return true;
}
protected abstract boolean checkWithdrawal(int
balanceAfterWithdrawal, int amountWithdrawn);
protected abstract void doWithdrawExtra(int
balanceAfterWithdrawal, int amountWithdrawn);
private final boolean passedCreditCheck() {
if (hadCreditCheck) return creditCheckOK;
creditCheckOK = Bank.doCreditCheck(getCustomerID());
return creditCheckOK;
}
...
}
Now nobody can make a subclass that can withdraw 100 without the
balance going down by 100, or go to a negative balance without a
credit check, or something like that. The doWithdrawExtra can do
additional tasks depending on the subclass that will occur when a
withdrawal is performed. One might give alerts on overdraft: if
(balanceAfterWithdrawal < 0) sendEmail(); -- likewise checkWithdrawal
allows some withdrawals to be denied, so an account type with no
overdraft allowed has if (balanceAfterWithdrawal < 0) return false; to
prevent it succeeding if it would cause overdraft.
In reality, this comes up most frequently in connection with
validation of some sort. To make all implementations of addFoo(Foo
quux) which sticks quux in a collection somewhere throw an NPE eagerly
if quux is null instead of blowing up somewhere far from the real
source of the error later when quux is pulled out of the collection,
you can avoid making an interface type with addFoo and make an
abstract class with code like this:
public final void addFoo (Foo quux) {
if (quux == null) throw new NullPointerException();
innerAddFoo(quux);
}
protected abstract void innerAddFoo (Foo quux);
Of course, some perverse subclasser might make innerAddFoo public or
call it from a new method that doesn't check its argument, but this is
like the privacy lock on a bathroom door, meant to stop unhappy
accidents rather than determined circumvention. The path of least
resistance to implementing addFoo is to simply override innerAddFoo
and do what comes naturally, and the argument gets checked for
validity this way. Whereas with an interface, the likely path of least
resistance
public void addFoo (Foo quux) {
myList.add(quux);
}
leads to difficulty down the road when someone inevitably puts a null
into the list through addFoo and the later exception traceback doesn't
point to anywhere near the culprit addFoo call.
So using an abstract class rather than an interface is sometimes a
design decision aimed at making implementations more robust and less
error-prone, or at least fail-fast.
Finally, a reason to use an abstract class AND an interface is to
provide a dummy implementation. This is common with observer pattern
listeners where the listener has multiple event-happened methods and a
particular listener is often only interested in one of them or some
proper subset of them. Implementing the interface means writing dummy
no-op methods for all of the others or it won't compile. So we get
classes like WindowAdapter that implement interfaces like
WindowListener that implement ALL of the eventHappened methods to do
nothing, and users can extend WindowAdapter and override just the one
eventHappened method to do something when the event happens.
Convenience is the purpose in this case. Of course since a vanilla
WindowAdapter is completely useless the class may as well be abstract.
(Indeed, this example is real -- the class
java.awt.event.WindowAdapter is part of the standard Java library and
it is abstract as of Java 6, and probably always has been.)
