• Post Reply Bookmark Topic Watch Topic
  • New Topic

when we use interface and abstract class?  RSS feed

 
sekhar kiran
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,
i know whats the interfaces and abstract class and also know that difference between interface and abstract class,but here my doubt is eventhough abstract class more advantage than the interface,then why should we use interfaces and when?
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sekhar kiran wrote:eventhough abstract class more advantage than the interface...

That's debatable. Personally, I'd say the exact opposite.

then why should we use interfaces and when?

You use interfaces to define types. As to the "why", I suggest you look at the tutorials because it would take too long to explain it all from scratch.

Winston
 
sekhar kiran
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
sekhar kiran wrote:eventhough abstract class more advantage than the interface...

That's debatable. Personally, I'd say the exact opposite.

then why should we use interfaces and when?

You use interfaces to define types. As to the "why", I suggest you look at the tutorials because it would take too long to explain it all from scratch.

Winston

what interface contains ,its all are present in abstract class.when would we prefer interface because its more advantage than interface
see interface has no instance variables but abstract had
interface had no subclass while abstract had
interface had no constructor but its possible in abstract
interfac had visibility public and abstract while abstract had public privet,abstract etc
 
Paweł Baczyński
Bartender
Posts: 2083
44
Firefox Browser IntelliJ IDE Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sekhar kiran wrote:what interface contains ,its all are present in abstract class.when would we prefer interface because its more advantage than interface
see interface has no instance variables but abstract had
interface had no subclass while abstract had
interface had no constructor but its possible in abstract
interfac had visibility public and abstract while abstract had public privet,abstract etc

A class can implement multiple interfaces. A class can't extend multiple classes (no matter if they are abstract or not).
 
sekhar kiran
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pawel Pawlowicz wrote:
sekhar kiran wrote:what interface contains ,its all are present in abstract class.when would we prefer interface because its more advantage than interface
see interface has no instance variables but abstract had
interface had no subclass while abstract had
interface had no constructor but its possible in abstract
interfac had visibility public and abstract while abstract had public privet,abstract etc

A class can implement multiple interfaces. A class can't extend multiple classes (no matter if they are abstract or not).

is that only feature which is advantage than the abstract
 
Campbell Ritchie
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No. An interface gives much more flexibility. Both have their uses.
 
sekhar kiran
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:No. An interface gives much more flexibility. Both have their uses.

we can declare methods in interface but we cant define ,but in abstract we can declare as well as we can define
then when we will use interface while developing in project because abstract can do all features which are available in interface
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

we can declare methods in interface but we cant define ,but in abstract we can declare as well as we can define

then when we will use interface while developing in project because abstract can do all features which are available in interface


Abstract classes cannot do everything an interface can. Take the following code as an example:



So by using interfaces the code is more flexible. Abstract classes are often used in conjunction with interfaces if there is an obvious or common template to the implementation.

However in Java 8 it is no longer even true that interfaces can't define methods. They can now have default methods, which are fully defined and functional.
 
Nilay Mitash
Greenhorn
Posts: 19
Hibernate Java Mac
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
First and foremost difference between abstract class and interface is that abstract class is a Class and interface is, well, an Interface.

What I am trying to tell you is, you cannot extend multiple classes in java but you can most certainly implement multiple interfaces.

Suppose you have a situation where you need to override multiple abstract methods from different abstract classes. You cannot do it because multiple inheritance by extending multiple classes is not possible in java.

This situation can be handled very well if you have multiple interfaces.

Another difference, all the methods in interface are implicitly public and abstract whereas in abstract class, you have to explicitly define the access level of the methods and also you have the choice to declare methods as abstract or not.

So, in the scenario of multiple inheritance, abstract classes are not suitable at all.
whereas, in the case where you don't want the overridden methods to be public, interfaces are not suitable.

But I personally find interfaces to be more useful because they provide more symmetry as compared to abstract classes.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16059
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
See also our FAQ page: Interface vs. abstract class.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nilay Mitash wrote:What I am trying to tell you is, you cannot extend multiple classes in java but you can most certainly implement multiple interfaces.

What you say is certainly true, but that's not the only reason to prefer interfaces over classes.

As soon as you have an implementation, you're stuck with it. FOREVER. If you're very good, you might be able to change it to some extent, but as soon as it becomes embedded in a hierarchy, it's likely to get more and more difficult to change because you'll have more and more classes "down the line" that rely on it.

Interfaces, on the other hand, have no such inbuilt restrictions, because they don't rely on any code.

Personally, I've found very little use for abstract classes except as 'skeleton' implementations of interfaces - and for that, they are very useful. But the interface comes first.

My 2¢.

Winston
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:

As soon as you have an implementation, you're stuck with it. FOREVER. If you're very good, you might be able to change it to some extent, but as soon as it becomes embedded in a hierarchy, it's likely to get more and more difficult to change because you'll have more and more classes "down the line" that rely on it.

Interfaces, on the other hand, have no such inbuilt restrictions, because they don't rely on any code.


I would say Interfaces suffer from the same restriction to some extent, especially if your code is used by third parties outside of your control. It's not possible to alter or extend an interface without breaking all code that is using it. I think the makers of Java came up against this restriction when they wanted to add Streams to Collections. Of course that has all changed with Java 8 (at least as far as extending interfaces) since you can now have default methods that include an implementation.

In Java 7 and earlier you can of course produce a new interface that extends the old one, but that can lead to overly complex class hierarchies and is less than ideal.

Winston Gutkowski wrote:Personally, I've found very little use for abstract classes except as 'skeleton' implementations of interfaces - and for that, they are very useful. But the interface comes first.


This I fully agree with. I don't think I've ever used an abstract class except as a partial implementation of an interface. And I try and enforce the general rule that all the dependencies of a class should be interfaces passed in to the constructor. This leads to loosely coupled, maintainable code. It also fits in very well with mocking frameworks such as Mockito. Expressing dependencies as well defined interfaces with good documentation leads to easily testable code in my experience. The areas of my project where this rule hasn't been adhered to are the areas that are most highly coupled, least well unit tested, and most prone to bugs. These are the areas that I look to refactor when possible.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike. J. Thompson wrote:I would say Interfaces suffer from the same restriction to some extent, especially if your code is used by third parties outside of your control. It's not possible to alter or extend an interface without breaking all code that is using it.

I'm not quite sure what you mean by "altering" an interface. An interface defines behaviour, so if you want to add to it, you might well extend it, but one would assume that you've actually worked out what behaviour is required.

I do understand (and I hope I'm not presuming) that when you've been dealing with code for a long while, your primary concern is how things work. Interfaces are almost the opposite. They deal with WHAT needs to be done; which is why they have NO code. The minute you start dealing with "how" (code) is when you tie yourself into decisions that may be irreversible.

And the nice thing, once you understand it - and it does take a bit of time - is that you can then start letting your imagination wander, because you're not constrained by all that horrible CODE.

What about a Dimension interface that allows you to create n-dimension objects or "space* (the final frontier?) A gamers' paradise, I would have thought. Or an Animal or Mammal interface that allows you to model characteristics to see if they're likely to survive.

These things are possible if you're not worried (or thinking about) the code which, unfortunately, is what preoccupies most of us. Java is both the gun AND its bullet, so unless you understand how the gun (and Object-Orientiation) works, you will never be a crack-shot.

Winston
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Mike. J. Thompson wrote:I would say Interfaces suffer from the same restriction to some extent, especially if your code is used by third parties outside of your control. It's not possible to alter or extend an interface without breaking all code that is using it.

I'm not quite sure what you mean by "altering" an interface. An interface defines behaviour, so if you want to add to it, you might well extend it, but one would assume that you've actually worked out what behaviour is required.


I simply meant any change to the interface. A change to parameters, a change to return types, an addition of methods, or even a removal of methods if the implementing code is following best practice and using @Override annotations. Any of those things will break all code that implements your interface since that code will no longer compile (with the exception of default methods in Java 8). So, you are still restricted to what changes you can make with interfaces if you are required to support backwards compatibility.
 
Piet Souris
Master Rancher
Posts: 2044
75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For me, the relevant question would be: how broad is the range of objects to which the interface
or abstract class are applicable?

We all understand the interface 'Comparable', and that it is applicable to a very broad range
of objects, so that it is worthwhile to make the interface generic.

When I modelled a Loan at the office, I knew it had to have methods like
double getFaceValue(), double getCurrentValue(int t), et cetera.

Now, it is clear that you could not use this for trees, cars, black holes and bottles of milk.
I therefore went for an abstract class here, so that everyone could subclass it for any specific loan
thinkable. I discovered that it is even possible to let an abstract class implement
an interface, like in



Greetz,
Piet
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!