• 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: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All,

Can anybody please explain me , when should we use an Abstract class and when should we use an Interface? Please give an example.

Thank You
Aparna
 
Ranch Hand
Posts: 206
Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In Java, you can extend only One class. So if you extend an Abstract class, then you cant extend any other class. So, Interface is better in this case.

An abstract class can contain non abstract methods, but in interface, all the methods are public abstract.
[ October 01, 2008: Message edited by: chander shivdasani ]
 
Aparna Misri
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank's a lot for your reply chander
but can you please elaborate your reply....

You said that if we will extend any abstract class we will not ab able to extend ant other class... same thing will happen I case of interface. If we will extend interface we will not be able to extend any other class.
 
Ranch Hand
Posts: 137
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One class can extend at most one class and can implement more than one interface. A class cannot extend an interface!

Refer to the following link for more information:
http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html
 
Ranch Hand
Posts: 58
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Abstract Class can have abstract and non-abstract method but all methods in interface are implictly abstract so you cannot have non-abstract class...in situation where you want to delegate whole stuff to concrete calss then you should declare interface otherwise abstract

Interface basically is used for declaring constants which are public final static .

since you can only extend one class but you can implement multiple interfaces
 
Aparna Misri
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot srilatha and mukki for your help
 
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Interface basically is used for declaring constants which are public final static .


interface and abstract both are used to achieve polymorphism.With abstract class we can provide default behaviour to subclass, but with interface you can't provide default behaviour.Each implementaion class(non-abstract) need to implement all the methods from interface.
Not only default behaviour we can also force sub class to use method from abstract class by declaring it final.
 
Aparna Misri
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks raj
 
Ranch Hand
Posts: 320
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, my thinking may not be correct, but here is how I think of this issue anyway.
I tend to think of abstract classes as the basis for designing/implementing specific functionality in terms of the "purpose and operation" of the object itself. I think of the abstract class as setting the "template" for defining "what an object is supposed to do".

I tend to think of the interface as the definition of how other classes call IN TO MY CLASS to use this classes functionality. In other words, to define the API in a manner of speaking.

What this separation buys you is this: Using abstract classes allows you to specify method names required to make the object do what the object is supposed to do.... more of an "internal to the object" point of view. The interface is used as a "how I can get this object to do what it does for ME" point of view.

Properly designed, you can use reference values of the interface type itself, NOT the class type. Thanks to polymorphism, the interface type reference variable will hold a reference to any class that implements the interface and the only methods that the caller can call are those specified by the interface. That enhances looser coupling. The calling class can't get at any of the methods specified by the class hierarchy, only the ones specified in the interface.

My favorite example of this is a custom "logging" facility. You can design a set of classes that facilitate data logging functionality to the screen, to files, to a network resource, to an "in memory" container, anything you want. Above them you wou8ld create an interface that specifies all methods that allow logging of data.

So you might have three classes defined:

class ScreenLogger implements Logger { ........ }
class FileLogger implements Logger { ........ }
class NetLogger implements Logger { ........... }

That means that each of those logging classes must implement the methods specified by the interface in such a way that they perform the requested logging for that class type according to the "contract" specified in the interface.

Now, when you want to use a logger, define a reference variable as the interface type:

Logger logType;

From here, any place that calls methods on the reference logType
(example logType.logDate() or perhaps logType.logPacket() each of these methods would have to be specified in the interface and implemented by each of the logging classes!)
will work, no matter which actual logging class is currently held in logType. This happens because of the adherence to the interface specification. Using the interface in this manner gives no visibility into the other methods that exist in the class because the interface variable doesn't have them defined.

I hope this helps...
[ October 01, 2008: Message edited by: Bob Ruth ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic