File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Beginning Java and the fly likes Interface vs AbstractClass Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Interface vs AbstractClass" Watch "Interface vs AbstractClass" New topic

Interface vs AbstractClass

Sainath Veepuri
Ranch Hand

Joined: Sep 25, 2003
Posts: 49
Hi all,
I'am looking for someone who can clear my doubt that struck to my little brain. I read that we cannot create an object for an abstract class. But I deliberately could create an object of the same.
Please throw a glance at the code below:

public abstract class MyAbstractClass {
public MyAbstractClass(){
System.out.println("creating MyAbstractClass object");
public abstract String methodOne();
public abstract String methodTwo();

public static void main(String a[]){

MyAbstractClass myAbstractClass = new MyAbstractClass(){

public String methodOne() {
public String methodTwo() {

}; // end of MyAbstractClass creation;


} // end of main

} // end of MyAbstractClass

This is the output I got:

creating MyAbstractClass object


Can I correlate this way:
Implementing an interface would require to define all the methods of the interface, whether they are required or not.
MouseListener (Interface)

Extending an abstract class, programmer would define methods of his choice.
MouseAdapter (Abstract Class)

In between, both Interfaces as well as Abstract classes cannot be instantiated in java. By default, an Interface itself is abstract and all the methods in an Interface are abstract. An Abstract class may or maynot have Abstract methods.

This was my answer for the difference between interface and abstract class in an interview. But the interviewer was not satisfied with my explanation
He asked me to think out of the box!

Would any one tell me the actual use of an abstract class over interfaces in java.

Barry Gaunt
Ranch Hand

Joined: Aug 03, 2002
Posts: 7729

This code is not creating an instance of your abstract class MyAbstractClass. It is creating an instance of a subclass of your abstract class. Your subclass provides the require implementation of the two abstract methods.

Ask a Meaningful Question and HowToAskQuestionsOnJavaRanch
Getting someone to think and try something out is much more useful than just telling them the answer.
Jimmy Die
Ranch Hand

Joined: Nov 20, 2003
Posts: 97

In your code you've declaired an anonymous class. By default it is a Subtype of your abstract class.

The interfaces vs. Abstract classes are very similiar. I liked your answers also. Maybe add the fact that you can only extend one abstract class, but you can implement many interfaces. This is a point that interfaces advantagous. For Interfaces an object is of a type if any of its superclasses implement the interface.

So for any concrete classes i.e. class SomeConcreteClass that implements interface A, then that class pass instanceof A test. If those same classes implement interface B then as well they pass instanceof test. Even though the interfaces A and B are not classes! Now if you have a concrete class that extends an abstract class ie. class CAbstractClass then there is only one possibility for passing the instanceof test, because of course only one class can be extended...

Hope that helps...

Jimmy Die
Sona Makheeja

Joined: Oct 25, 2004
Posts: 11
As you are implementing the abstract class then n there, and implementing the abstract methods, as Barry says, it is the subclass actually returning the results.
But the answer as to the difference between the interface and abstract class is still to be answered. as per me, the answer given by you is OK
Sainath Veepuri
Ranch Hand

Joined: Sep 25, 2003
Posts: 49
Hi all,
Let me thank you for your prompt responses
Also, I'am sorry that I overlooked my code and was under a different illusion, Ya, it was creating an instance of a subclass but not of the original class.

About the difference between... Interfaces vs Abstract classes, I was really expecting some different answers. I mean interms of performance..etc etc.
But there might be some special use of abstract classes why they have been introduced. Mean while I would surf the net and let you know once I find them.
Thankyou again,
Paul Sturrock

Joined: Apr 14, 2004
Posts: 10336

Would any one tell me the actual use of an abstract class over interfaces in java

I never use abstract classes if I can help it. So-called "concrete" inheritance (i.e. the use of abstract classes) tends to make code changes in future versions a much bigger job than it need be. With "abstract" inheritance (the use of interfaces instead) you are much more free to make changes.

JavaRanch FAQ HowToAskQuestionsOnJavaRanch
David Harkness
Ranch Hand

Joined: Aug 07, 2003
Posts: 1646
First, Sai, the performance difference between an interface and abstract class is aking to the difference between using an int vs. a long. Ninety-nine times out of a hundred, you're splitting hairs. Performance impacts mostly come in choosing an algorithm for your large task rather than tiny details like this.

Originally posted by Paul Sturrock:
I never use abstract classes if I can help it.
For framework code (Dao, Entity, etc) I tend to mix both: an Entity interface and an AbstractEntity that implements Entity with the least-likely-to-change behavior.

For example, my domain object interface hierarchy contains Identifiable (get/setId), Auditable (get/setCreatedDate, get/setModifiedDate, get/setVersionNum) and Validatable (validate). Then I create abstract classes based on the most likely use cases.

Since all domain objects are Identifiable, yet some aren't Auditable or Validatable, I created AbstractEntity (implements Identifiable). Then, since more are Auditable than Validatable, I created AbstractAuditableEntity and finally AbstractAuditableValidatableEntity.

This saves me from duplicating the standard Identifiable and Auditable implementations in every domain object. I favor interfaces first, and then provide abstract implementations if I expect to have multiple slightly-varying concrete implementations.

Keep in mind that it has taken many years of experience to get to the point of being able to anticipate what the concrete subclasses will override before writing them. As well, by using abstract classes you can use refactoring tools to move common code to the abstract class. This is not possible with interfaces.
Paul Sturrock

Joined: Apr 14, 2004
Posts: 10336

DAO's are probably one of the few areas where I'd use abstract classes. After all theres always an exceptions to the rule! Which is incidentally the same reason why I tend to avoid abstract clases in the first place. Its true a good refactoring tool can reduce the effort of reworking code in line with changes to abstract classes, but in my experience on anything but a relatively small application such refactoring is never trivial. Especially if an applicaiton uses things like reflection or external mapping files.
I agree. Here's the link:
subject: Interface vs AbstractClass
It's not a secret anymore!