Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Difference between abstract class and interface?  RSS feed

 
Mohammad Ashari Rahman
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

What is the Difference between abstract class and interface?
What are the conceptual differences and why we need the two distinctions if methods in both need to be defined?
 
Campbell Ritchie
Marshal
Posts: 55694
163
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Start with our FAQ (#21).
 
Tushar Goel
Ranch Hand
Posts: 934
4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is some similarity as well. Both are working as contract as well. Implemented/Extended class should have provide all the mentioned
functionality.
 
Mohammad Ashari Rahman
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks lot of info on java
 
Winston Gutkowski
Bartender
Posts: 10573
65
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mohammad Ashari Rahman wrote:What is the Difference between abstract class and interface?
What are the conceptual differences and why we need the two distinctions if methods in both need to be defined?

The main conceptual difference is that an interface only describes what a type does; while a class - any class - also describes at least part of how it does it (ie, implementation code).

If only part of the "how" is implemented - ie, some methods are left "empty" - then it must be an abstract class; otherwise it is normally a "concrete" class.

This division between "what" and "how" is a very important aspect of OO design, because it allows us to specify a type without having to worry about how it works, which can be extremely useful for dividing a complex program or application up into discrete "tasks".

For example, if I know that my class needs to contain a stack, then I can simply write a Stack interface - perhaps with push(Object), pop() and peek() methods (the "classic" requirements for a stack) - and hand it off to someone else to implement while I concentrate on what MY class has to do.
Or, if I don't have anyone else to help me, I can simply leave it as an interface until I'm ready to tackle it myself.

Furthermore, providing I only ever use Stack in my class, I can make use of any future improvements to the design by simply changing the place(s) where they are initialized, viz:
  Stack s = new BasicStack();
becomes:
  Stack s = new ImprovedStack();
and nothing else in my program needs to change.

It's called programming to the interface and it's a very useful habit to get into, because it has other advantages too.

It's probably worth mentioning that the two things aren't mutually exclusive: Some interfaces lend themselves to "skeleton implementations" that work for most people and take a lot of the drudge out of implementing the interface from scratch.
One such class is AbstractList, which is an abstract implementation of Java's List interface that allows you to create fully-functional List classes by implementing as few as 2 methods (List itself has 32 these days).

HIH, and I hope I haven't "overloaded" you.

Winston
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!