This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Interface OR Abstract Class  RSS feed

 
Nikita Dutt
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi All,

May be this is not a very appropriate question for this forum but not sure where to post it. In terms of design (Gang of Four) when should we use an interface and when should go for a abstract class. ? I know one lame explanation its better to with interface always as we can implement multiple interface in a Java Class where multiple inheritance of class is not possible.


Would really appreciate if i can get some better pointers on this .


Thanks in advance
 
Javad Rashidi
Ranch Hand
Posts: 34
Java MySQL Database Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
when you don't want your class be instanceable, declare it as abstract. in an interface you declare the steps or the way but how to done the steps is left blong to class that implements
the interface. for example the power button in pc and TV both do one job "TURN ON the system" but the process of TURN ON in each system is different,
 
Riaan Nel
Ranch Hand
Posts: 160
IntelliJ IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nikita Dutt wrote:
Hi All,

May be this is not a very appropriate question for this forum but not sure where to post it. In terms of design (Gang of Four) when should we use an interface and when should go for a abstract class. ? I know one lame explanation its better to with interface always as we can implement multiple interface in a Java Class where multiple inheritance of class is not possible.


Would really appreciate if i can get some better pointers on this .


Thanks in advance


When you need some predefined logic to be common to all instances of your interface/abstract class, use an abstract class and write that logic in the abstract class.

As an example, imagine that you have to write classes to represent cars. All cars have lights, but they have a different number of doors. You'll write a method to turn on the lights in an abstract super class, but you'll have an abstract getNumberOfDoors() methods to be overwritten on each subclass. E.g. if you call turnOnLights() on BMWCar and on PorscheCar, the same code will be executed for both of them, from the superclass. Your abstract getNumberOfDoors() method, however, might return 4 for BMWCar and 2 for PorscheCar.
 
Campbell Ritchie
Marshal
Posts: 55698
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not a very good example; you would have numberOfDoors as a fieldMore that Vehicle could be an abstract class, with Car, Bus, Van etc as concrete subclasses. Note that most of the data, eg number of doors, and much of the behaviour, eg turning lights on and off, are incorporated in the Vehicle class. That is where an abstract class is useful; you can't incorporate instance data in an interface. When you consider all the options available for a Vehicle, eg colour, engine size, make, you are going to have a very large constructor

There are a few methods, eg pickUpFriends (Car), pickUpGoods (Van) or collectFares (Bus) which are peculiar to the different concrete subclasses.
 
Nikita Dutt
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Thanks what i have understood after reading the post and some googling is

"When we inherit behavior by sub classing, that behavior is set statically at compile time. In addition, all subclasses must inherit the same behavior. If however we can extend an object’s behavior through composition, then I can do this dynamically at runtime."

So if we are looking for some runtime behavior only , interfaces are better option ; if a type matching is required for example Car , Van are kinds of Vehicle ; go for abstract class


Hope i make sense
 
Campbell Ritchie
Marshal
Posts: 55698
163
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"When we inherit behavior by sub classing, that behavior is set statically at compile time. In addition, all subclasses must inherit the same behavior. If however we can extend an object’s behavior through composition, then I can do this dynamically at runtime."
Where on earth did you find that? It looks at best confusing.
 
Matthew Brown
Bartender
Posts: 4568
9
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nikita Dutt wrote:"When we inherit behavior by sub classing, that behavior is set statically at compile time. In addition, all subclasses must inherit the same behavior. If however we can extend an object’s behavior through composition, then I can do this dynamically at runtime."

That's discussing the difference between inheritance and composition, which is something else again. It's not really related to Abstract classes v Interfaces.

I'd put it like this. If you want to define what the behaviour should be, use an interface. If you want to actually provide some of this behaviour to be used by subclasses, or you want to provide a default implementation, you need to use an abstract class.

And remember, you can use both. It's fairly common to have an interface defining what the behaviour should be, then an abstract class providing some of the implementation. Then, other classes can implement the interface directly if they want, but often it will be easier to use the abstract class. For an example, see java.util.List (an interface) and java.util.AbstractList (an abstract class that is a base class for both ArrayList and LinkedList).
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!