Abstract Class Vs Interface

[Lakshmi Ashok]

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. "

[Jeff Albertson]

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]

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 {
...
}

[Clifton Craig]

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]

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...

[Mr. C Lamont Gilbert]

An abstract class can force a particular implementation on its children by, for instance, making one of its methods final.

[Naseem Khan]

Also go on artima site and see the following material...

Objects and Java by Bill Venners

regards

Naseem Khan

[Garrett Rowe]

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!

[Allen Bandela]

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]

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