• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Interface and Abstract Class

 
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
Can anybody tell in detail in what instance you go for Interface and in what case you go for Abstract class
Thx in advance
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ,
Although my explanation is not exhaustive, here are the few thumb rules that you can use to make the decision
----- If you want to specify only the contract and no implementation then go for an Interface. If you want to specify the contract and optionally a partial implemenation then go for the Abstract Class.
----- Interface would give you greater flexibilty than abstract classes.
Firstly in a language like Java which does not support multiple implementation inheritance, using a abstract class would mean that we no longer can extend another class that would be essential as per the design. Thus we have to prefer an Interface over the Abstract Class
Secondly using an Interface would be a more meaningful design decision and would model the real world in a better way.
Consider the following classes:
class Circle{}
class Dog {}
Now in this case there are 2 different class heirarchies with no commonality between them. Suppose we require a contract with the method move() in all the classes. There are 2 options for this
-- We can use an abstract class Moveable with the method move()
abstract class Moveable
{
abstract void move();
}
We can then change the design as follows
class Circle extends Moveable{}
class Dog extends Moveable{}
However this is not a good design because
1. It does not model the real world in the right way. The classes Dog and Circle have nothing in common and should ideally be placed in different hierarchies
2. It does not allow us to extend from another class. In the real world the situation would be as follows
class Shape{}
class Circle extends Shape{}
class Pet{}
class Dog extends Pet{}
this being the case, we can no longer extend from class Moveable at the same time.
Thus the better design in this case would be an Interface as shown
interface Moveable
{
void move();
}
class Shape{}
class Circle extends Shape implements Moveable{}
class Pet{}
class Dog extends Pet implements Moveable{}

Finally although abstract classes and interface are used to leverage polymorphism, it is always better to program to the interface rather than the implementation.
-Sirish
[ February 07, 2004: Message edited by: Sirish Kumar ]
 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sirish,
Nice reply. It helps in area I was fuzzy about.


However this is not a good design because
1. It does not model the real world in the right way. The classes Dog and Circle have nothing in common and should ideally be placed in different hierarchies
2. It does not allow us to extend from another class. In the real world the situation would be as follows


In your comments above it seems like there is another reason it is not good design:
3. It does not maintain the is-a relationship correctly. A circle is not a Moveable and a dog is not a Moveable.
 
reply
    Bookmark Topic Watch Topic
  • New Topic