File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Beginning Java and the fly likes abstract Vs interface : usability Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "abstract Vs interface : usability" Watch "abstract Vs interface : usability" New topic
Author

abstract Vs interface : usability

naveen yadav
Ranch Hand

Joined: Oct 23, 2011
Posts: 384


when should one use abstract class ?

and

when one should use interface ?
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3646
    
  16

Hi Naveen. This question has been asked on many an occasion. Please SearchFirst.

Click
naveen yadav
Ranch Hand

Joined: Oct 23, 2011
Posts: 384

after goggling what i found is :

USE abstract class:
to provide the default behavior to the child classes AND you don't want to a class to be instantiated.

USE interface:
if you want that a class(s) should provide their own implementation.


share your opinion.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3646
    
  16

Personally I think making a class abstract is a poor way of making it uninstantiable. If this is what one wants, they should add a private constructor to the class.

The rest is correct though. I usually use interfaces to define data types, and sometimes implement that interface with an abstract class to provide default behaviour for some or all of the methods.

You probably shouldn't create an abstract class without also providing an interface that the abstract class implements. Remember, abstract classes are for behaviour, interfaces are for types.
naveen yadav
Ranch Hand

Joined: Oct 23, 2011
Posts: 384

Stephan van Hulst wrote: abstract classes are for behaviour, interfaces are for types.


that is something new .

thanks Stephan van Hulst.
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Stephan van Hulst wrote:Remember, abstract classes are for behaviour, interfaces are for types.

I don't really understand what you mean by this.

An interface defines a set of behaviors without specifying the details of those behaviors. An abstract class defines the details. But an abstract class also binds its implementing classes to its class hierarchy. Consider an interface Pourable and an abstract class Bottle. A class that implements Pourable can pour() without having to be a Bottle; it could be a PaintCan or a RainStorm instead. But a class that extends Bottle will have the benefit of inheriting all of Bottle's attributes and behaviors. We know, when we use a WineBottle, that everything that is true of Bottle is true of WineBottle. But when we use a Pourable, all we know is that it can pour(); we don't know how, and we don't know what, it is pouring.

So I would say: Use an abstract class as a foundation for a family of closely related objects with behaviors that may vary. Use an interface when the important thing is that a behavior exists, and it doesn't matter what thing is behaving.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3646
    
  16

What I mean by "type" is that interfaces should be used to define structures that you work with. By "behaviour" I mean the implementation of such a structure.

We're talking about the same thing, but the words I used might have been a bit confusing.

Anyway, I don't think you should use abstract classes as the base of a hierarchy unless it implements some interface. Actually, this goes for normal classes as well. Case in point: InputStream.

InputStream should have been an interface, with a separate AbstractInputStream class that provides the default implementation that the current InputStream class has.

Bottle is a useful starting point to implement a WineBottle, but we shouldn't have an abstract Bottle without also providing the "type" we care about: Pourable. We don't care about Bottle's "type". We only care about its "behaviour".
Randall Twede
Ranch Hand

Joined: Oct 21, 2000
Posts: 4347
    
    2

y'all covered it quite well. looking at it slightly differently. i can write a class that implements MouseListener and MouseMotionListener and have to write a bunch of do-nothing methods when instead i can use an abstract class(lucky me java supplies one) MouseAdapter. now i only have to write the methods i actually override.


SCJP
Visit my download page
Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
I can think of one more widely used example - Using an abstract Data Access Object(DAO) class. You could code away the most simple and reusable methods like DB Insert/Fetch/Update/Delete in 1 abstract class and you could create separate interfaces for different tables. These interfaces would contain specific functions pertaining to that table. You could then create table wise implementations that would extend the same abstract class and implement table wise interfaces.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: abstract Vs interface : usability