[ACCEPTED]-Do/can abstract classes replace interfaces?-abstract-class

Not always:

• a class can extend only one class
• a class can implement more than one interface

Sun docs make a more detailed comparison:

Abstract 20 Classes versus Interfaces

Unlike interfaces, abstract 19 classes can contain fields that are not 18 static and final, and they can contain implemented 17 methods. Such abstract classes are similar 16 to interfaces, except that they provide 15 a partial implementation, leaving it to 14 subclasses to complete the implementation. If 13 an abstract class contains only abstract 12 method declarations, it should be declared 11 as an interface instead.

Multiple interfaces 10 can be implemented by classes anywhere in 9 the class hierarchy, whether or not they 8 are related to one another in any way. Think 7 of Comparable or Cloneable, for example.

By 6 comparison, abstract classes are most commonly 5 subclassed to share pieces of implementation. A 4 single abstract class is subclassed by similar 3 classes that have a lot in common (the implemented 2 parts of the abstract class), but also have 1 some differences (the abstract methods).

In some cases you can use an abstract class 7 instead of interface. However, it is hardly 6 ever a good idea to do so. In general you 5 should use the rule:

1. Interfaces specify behaviour.
2. Abstract classes specify implementation.

The other "problem" with 4 using abstract classes is that you can then 3 no longer implement mixins, that is you 2 can implement multiple interfaces, however 1 you can only extend one abstract class.

One point missing from the answers here 17 is the idea of who will be implementing the 16 interface.

If your component wants to return instances 15 of abstract types to its callers, where 14 the concrete types are defined internally and hidden from 13 callers, use an interface. Conversely, if your component 12 consumes or accepts instances of abstract types that its callers must 11 implement, abstract classes are usually a better choice.

Anticipating 10 evolution and maintaining binary compatibility 9 tips the scales here. With an abstract class, you 8 can add methods and, if you provide a base 7 implementation, existing implementations of the 6 abstract class will continue to work fine. With 5 an interface, adding a method breaks binary 4 compatibility, for no existing implementation 3 could possibly continue to compile properly 2 without changing to define the new method.

The 1 Apache Cactus project has a good discussion on how to resolve these obligations.

To answer your question, yes you could use 7 an abstract class (providing no implementation) instead 6 of an interface but I'd consider this bad 5 practice:

• You've used up your "one-shot" at inheritance (without gaining any benefit).
• You cannot inherit from multiple abstract classes but you can implement multiple interfaces.

I would advocate the use of abstract 4 classes more in situations where you wish 3 to provide a partial implementation of a 2 class, possibly delegating some behavior 1 to concrete subclass implementations.

• A class in java can inherit from multiple 4 interfaces, but only from one abstract class.

• An 3 interface cannot define any code, in an 2 abstract class, you can define code (i.e. default 1 behaviour of methods)

Abstract classes and interfaces are complementary.

For 9 instance when creating an API you will want 8 to present interfaces to the client, so 7 that you may always completely change the 6 implementation whereas he does not have 5 to change its code and the user does not 4 rely on implementation when building using 3 your API but just on methods contracts.

Then 2 you will have abstract classes partly implementing 1 these interfaces, in order to

• share some common code, which might be used in all (or almost all) implementations for interface, which is obvious
• provide default behaviour which could be overridden in 'real' implementations, for instance a toString() method using interfaces methods to create a textual representation of the implementation
• preserve implementations compatibility after interface changes, for instance when you add a new method in your interface, you also add a default implementation in the abstract class so that implementations (for instance those made by the user) extending the abstract class still work without changes

Interfaces are much cleaner and light weight. Abstract 2 classes make you dependent on it heavily 1 as you cannot extend any other classes.

Have a look at the interesting article "Why extends is evil" to 3 get an idea about the differences between 2 interface implementation and class inheritance 1 (beside the obvious multi- single restrictions)

Abstract classes are the partial implementation 13 of Abstraction while Interfaces are the 12 fully implementation of Abstraction.Means 11 in Abstract classes we can put methods declaration 10 as well as method body. We can't create 9 an object of Abstract classes(association) and 8 reuse the class by inheritence(not by association). By 7 default in interfaces all declared variables 6 are static final and All methods are public.

For Example: In 5 JDK there are only few abstract classes 4 and HttpServlet is one of them which is 3 used in Servlet.So we can't create object 2 of HttpServlet and it can be used only by 1 inheritence.

Main use of interface is when you create 5 the reference of interface and call the 4 method of particular class that's resolved 3 at runtime. So it's always better idea to 2 create reference of interface to call the 1 method.