My OperaJava Questions - 002
Thursday, November 9, 2006 6:32:27 PM
What’s the difference between an abstract class and an interface?
interface:
A class may implement several interfaces. An interface cannot provide any code at all, much less default code.
Static final constants only, can use them without qualification in classes that implement the interface. On the other paw, these unqualified names pollute the namespace. You can use them and it is not obvious where they are coming from since the qualification is optional.
An interface implementation may be added to any existing third party class. Interfaces are often used to describe the peripheral abilities of a class, not its central identity, e.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects.
You can write a new replacement module for an interface that contains not one stick of code in common with the existing implementations. When you implement the inteface, you start from scratch without any default implementation. You have to obtain your tools from other classes; nothing comes with the interface other than a few constants. This gives you freedom to implement a radically different internal design.
If your client code talks only in terms of an interface, you can easily change the concrete implementation behind it, using a factory method.
Slow, requires extra indirection to find the corresponding method in the actual class. Modern JVMs are discovering ways to reduce this speed penalty.
The constant declarations in an interface are all presumed public static final, so you may leave that part out. You can’t call any methods to compute the initial values of your constants. You need not declare individual methods of an interface abstract. They are all presumed so.
If you add a new method to an interface, you must track down all implementations of that interface in the universe and provide them with a concrete implementation of that method.
abstract class:
A class may extend only one abstract class.
An abstract class can provide complete code, default code, and/or just stubs that have to be overridden.
Both instance and static constants are possible. Both static and instance intialiser code are also possible to compute the constants.
A third party class must be rewritten to extend only from the abstract class.
An abstract class defines the core identity of its descendants. If you defined a Dog abstract class then Damamation descendants are Dogs, they are not merely dogable. Implemented interfaces enumerate the general things a class can do, not the things a class is.
In a Java context, users should typically implement the Runnable interface rather than extending Thread, because they’re not really interested in providing some new Thread functionality, they normally just want some code to have the capability of running independently. They want to create something that can be run in a thread, not a new kind of thread.The similar is-a vs has-a debate comes up when you decide to inherit or delegate.
You must use the abstract class as-is for the code base, with all its attendant baggage, good or bad. The abstract class author has imposed structure on you. Depending on the cleverness of the author of the abstract class, this may be good or bad.
If the various implementations are all of a kind and share a common status and behaviour, usually an abstract class works best.
Just like an interface, if your client code talks only in terms of an abstract class, you can easily change the concrete implementation behind it, using a factory method.
Fast
You can put shared code into an abstract class, where you cannot into an interface. If interfaces want to share code, you will have to write other bubblegum to arrange that. You may use methods to compute the initial values of your constants and variables, both instance and static. You must declare all the individual methods of an abstract class abstract.
If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without change.
interface:
A class may implement several interfaces. An interface cannot provide any code at all, much less default code.
Static final constants only, can use them without qualification in classes that implement the interface. On the other paw, these unqualified names pollute the namespace. You can use them and it is not obvious where they are coming from since the qualification is optional.
An interface implementation may be added to any existing third party class. Interfaces are often used to describe the peripheral abilities of a class, not its central identity, e.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects.
You can write a new replacement module for an interface that contains not one stick of code in common with the existing implementations. When you implement the inteface, you start from scratch without any default implementation. You have to obtain your tools from other classes; nothing comes with the interface other than a few constants. This gives you freedom to implement a radically different internal design.
If your client code talks only in terms of an interface, you can easily change the concrete implementation behind it, using a factory method.
Slow, requires extra indirection to find the corresponding method in the actual class. Modern JVMs are discovering ways to reduce this speed penalty.
The constant declarations in an interface are all presumed public static final, so you may leave that part out. You can’t call any methods to compute the initial values of your constants. You need not declare individual methods of an interface abstract. They are all presumed so.
If you add a new method to an interface, you must track down all implementations of that interface in the universe and provide them with a concrete implementation of that method.
abstract class:
A class may extend only one abstract class.
An abstract class can provide complete code, default code, and/or just stubs that have to be overridden.
Both instance and static constants are possible. Both static and instance intialiser code are also possible to compute the constants.
A third party class must be rewritten to extend only from the abstract class.
An abstract class defines the core identity of its descendants. If you defined a Dog abstract class then Damamation descendants are Dogs, they are not merely dogable. Implemented interfaces enumerate the general things a class can do, not the things a class is.
In a Java context, users should typically implement the Runnable interface rather than extending Thread, because they’re not really interested in providing some new Thread functionality, they normally just want some code to have the capability of running independently. They want to create something that can be run in a thread, not a new kind of thread.The similar is-a vs has-a debate comes up when you decide to inherit or delegate.
You must use the abstract class as-is for the code base, with all its attendant baggage, good or bad. The abstract class author has imposed structure on you. Depending on the cleverness of the author of the abstract class, this may be good or bad.
If the various implementations are all of a kind and share a common status and behaviour, usually an abstract class works best.
Just like an interface, if your client code talks only in terms of an abstract class, you can easily change the concrete implementation behind it, using a factory method.
Fast
You can put shared code into an abstract class, where you cannot into an interface. If interfaces want to share code, you will have to write other bubblegum to arrange that. You may use methods to compute the initial values of your constants and variables, both instance and static. You must declare all the individual methods of an abstract class abstract.
If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without change.
