• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

Abstract Class Vs Interface

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An abstract class can be termed as : Interface + A class you want to extend.

SO, why would anybody not use just the "Interface + A class you want to extend. "
 
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's not clear to me but are you asking, "why ever define an interface Foo when you can use an abstract class AbstractFoo"?


You can extend an existing class x and have it implement Foo, but Java forbids extending both X and AbstractFoo:

class MyClass extends X implements Foo {}
class MyClass extends X, AstractFoo {}

Also, nothing says you can't define and use both: this is a common situation:

interface Foo {
...
}

abstract class AbstractFoo implements Foo {
boilerplate code
}

//then perhaps...
class DefaultFoo extends AstractFoo {
...
}

//or...
class SpecificDefnFoo extends X implements Foo {
...
}

Take a look at the component models in Swing, for example TableModel for an example of this.

Also, some techniques like dynamic proxies formally require interfaces, not abstract classes, to work.
 
Lakshmi Ashok
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was asked to explain what is the difference bw choice 1 and choice 2....(in an interview)

Choice 1:
abstract class AbstractFoo {
boilerplate code

Some methods (which could have been a part of an interface)
that need to be overridden in the child.
}

//then perhaps...
class DefaultFoo extends AstractFoo {
...
}

choice 2
class SpecificDefnFoo extends X implements Foo {
...
}
 
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lakshmi,

Long answer: The difference is in the clients that use the interface/abstract class. To the implementor it makes no difference whether to use an interface or an abstract class (except that one involves an extra file and appears to be more work... a dangerous assumption). The client of said abstract class or interface will face certain challenges depending on the choice. If an interface is not used then the client is bound to an implementation which is subject to change. However if an interface is used then the client is free from effects/defects as the implementation changes. Considering that even default implementations are subject to change, it makes more sense to use an interface in many situations. The other end of the problem is how the client code gets a reference to the interface or abstract class. if the client creates it directly via the "new" keyword then the client is bound to an implentation regardless of which choice is made. Good O-O principle says that you should depend in the direction of stability so it's always safer to have both the implementation and the client depend on the interface since they change less frequently than the implementation.

The short answer is, when in doubt use an interface.
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Clifton Craig:

The short answer is, when in doubt use an interface.



Good summary Clifton. But for the sake of completeness here's a commonly mentioned reason that may make an abstract class more desirable over an interface.

Suppose you are using the acme.com library, version 1.7. If many of your classes implement its interface Foo, you will in trouble when you switch to version 2.0, which adds seven new methods to Foo. Then all of your concrete Foo implementations won't compile because the compiler insists they should be declared abstract! If you had your classes extend AbstractFoo you'd be laughing, because version 2.0 of AbstractFoo provides default implements of the seven new Foo methods...
 
Ranch Hand
Posts: 1170
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An abstract class can force a particular implementation on its children by, for instance, making one of its methods final.
 
Ranch Hand
Posts: 809
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also go on artima site and see the following material...

Objects and Java by Bill Venners

regards

Naseem Khan
 
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeff Albertson:


Good summary Clifton. But for the sake of completeness here's a commonly mentioned reason that may make an abstract class more desirable over an interface.

Suppose you are using the acme.com library, version 1.7. If many of your classes implement its interface Foo, you will in trouble when you switch to version 2.0, which adds seven new methods to Foo. Then all of your concrete Foo implementations won't compile because the compiler insists they should be declared abstract! If you had your classes extend AbstractFoo you'd be laughing, because version 2.0 of AbstractFoo provides default implements of the seven new Foo methods...



I hate when acme does stupid stuff like this. If only they would have extended the Foo interface with a new interface they wouldn't have broken all that existing code. Everyone knows that changing a published interface just shouldn't be done. Incompetence runs through the Acme corporation like a virus. That why they are being sued here in Arizona. I hope Mr. Coyote puts them out of business for good!
 
Ranch Hand
Posts: 128
MS IE Eclipse IDE Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeff Albertson:


Suppose you are using the acme.com library, version 1.7. If many of your classes implement its interface Foo, you will in trouble when you switch to version 2.0, which adds seven new methods to Foo. Then all of your concrete Foo implementations won't compile because the compiler insists they should be declared abstract! If you had your classes extend AbstractFoo you'd be laughing, because version 2.0 of AbstractFoo provides default implements of the seven new Foo methods...



Why will the compiler give an error saying "the implementations should be declared abstract"? Would'nt the message rather be "all interface methods are not implemented"?
 
Jeff Albertson
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Allen Sylvester:
Why will the compiler give an error saying "the implementations should be declared abstract"? Would'nt the message rather be "all interface methods are not implemented"?



To be picky, the error message is compiler-implementation. I get the following:

DefaultFoo is not abstract and does not override abstract method bar() in Foo
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic