• 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

Abstract classes vs. interfaces

 
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Akshay Bhatia:
under what circumstances one should use abstract classes instead of
interfaces?


Whenever I use an interface, I generally provide a BaseFoo abstract class that implements the behavior I expect will be the same across all implementations.

A good example are Collection and AbstractCollection. Collection defines getSize(), and AbstractCollection provides a base implementation by tracking the current size in an int member variable and returning it with getSize(). List, Stack, Queue, Tree, Map -- they all can use the same implementation, merely modifying the size member as they see fit. There's no point in each of them declaring the same member variable and accessor.

However, if you have an interface and expect either multiple implementations of your own or that other people will create their own implementations, you may find an abstract class to be helpful.

I cannot think of a reason that I would use an abstract class without an interface, except possibly for trivial callback objects. Just remember that by using an abstract class instead of an interface, you are forcing the developer to extend your class.
 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thnx everybody.

akshay.
 
Akshay Bhatia
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
under what circumstances one should use abstract classes instead of
interfaces?

Akshay.
 
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Abstract class may contain methods and attributes common to derrived classes. Interface can not contain any implementation details.

Interface is more OO in my opinion. In Java you can derrive only from one class (and implement as many interfaces as you wish). So once you derrive from abstract class your children class can not be derrived from any other class. If you use simple interface then you can derrive your implementation from whatever class you want.

I would put that common functionality into separate classes and use interface in most cases.
 
Vladas Razas
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry probably didn't answer your question directly. I wouldn't use abstract classes usually.
 
Ranch Hand
Posts: 128
Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Usage of Abstract Classes
I could give you a practical Example. We could use Abstract Classes when the functionality can be more or less decided. so you could implement these methods in advance and then provide "fill in the blanks" to the developer of the concrete subclass of this Abstract class.

I used a similar approach in developing a Product Catalog, which has a "pre-Loaded" Data base in a number of Hashmaps, with keys being the PKs of each row and the Value being a Java Bean format Data Base Object.

I created a "AbstractProductCatalog" which has declared fields of Hashmaps initialized to null. and all implemented System interface APIS like "getProductById(int nProdId)" etc. the Abstract class knows that the "PRODUCT_CACHE" contains the Product Data, so the implemented getProductById would query this Hashmap.

Now I force the Sub classer to "fill" the Product Hashmap through a abstract method. "public abstract void initProductCatalog();" ( or more detailed Methods which would fill each Business Object.



Usage of Interface

This is a very tricky one, as interfaces are themselves not usable / instantiable, they can be used to achieve goals to make an system more adaptible and also more reusable.
some scenarios:
1.

A class if it implements an interface can represent an Object another system expects with a simple cast. this will be useful when
we want to make "Plug and Play" possible. example : we do this when we want to serialize an Object. all we need to do is that we implement the method Serializable and the JVM needs only to know if this class is serializable or not.

2.
Interfaces can be used as the "messengers" between two systems, where the receiving system need to know only the interface and not have the whole other systems library in its path all you need is some middle tier code ( generally using reflection so that it could inturn look in the same VM or a different VM) and request the interface. ( I tried to do give an example below )

3.
Simply you could define interfaces and let the providor implement all the Logic, all you do is know how to get that interface and start using the interfaces. a good example is the SQL API, where all the APIS are interfaces and they are implemented by the Database vendors or some third parties. so no wonder what Database you code to, as long as you are using the SQL API and you have a driver you can do Database Access coding in your applications.

Example:

Lets say that there is a new requirement to provide a GUI front end to the same Product Catalog that we created above. so in order to make best the concept of re-usability, we could now create a new interface called AbstractProdCatalogIntf so that the client can be made very thin and need to have only the Java Beans (getters and setters for an entity) and the interface in its path.

public interface AbstractProdCatalogIntf
{
// declare all the methods like
public Product getProductbyId(int nProdId) throws BusinessException;
public void initialize();

}

//Then make the AbstractProductCatalog implement the Interface with the other things being same.

now I create a new application which Extends JFrame.

public ProdCatFrontEnd extends JFrame
{

AbstractProdCatalogIntf aInterface = someGenericClassUsingReflection.getProductCatalog();
//start Using the interface

}




}



Note that the implementation of the interfaces is not very clear...but I hope it atleast tries to hit the point. And Sorrz if I created too much confusion
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Vladas Razas:
Sorry probably didn't answer your question directly. I wouldn't use abstract classes usually.



I use them regularly to provide common implementation to subclasses, for example using the Template Method pattern.

What do you do in those cases???
 
Ranch Hand
Posts: 374
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by David Harkness:

Whenever I use an interface, I generally provide a BaseFoo abstract class that implements the behavior I expect will be the same across all implementations.



I've come to think of it the other way around. Whenever I feel it would work well to create an abstract class, I create an interface to match its public methods. IMHO this is more appropriate, because in some cases you either
a) won't have any preconceived notion of how implementations will behave
or
b) will expect every implementation to act completely differently.

Consider a J2EE filter implementation. Sun has no idea what you're going to write, or its flow, so there's not much point in them trying to build a base abstract class.

On the other hand, when you build an abstract class you'll inevitably find a spot where polymorphism would save your behind, but you can't pass an instance of the class you want because it's already got a different parent!
 
Akshay Bhatia
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
plz. give some scenario fo it.


Akshay.
 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
JDCTechTips has an article on "Abstract Classes vs Interfaces", here.

Joyce
 
Ranch Hand
Posts: 315
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Joyce.
reply
    Bookmark Topic Watch Topic
  • New Topic