I can provide two types of "real world" examples -- one from the business world and onw from the true "real world." Real World: You have an Animal class. It is an abstract class, because you cannot instantiate a generic "Animal," but it provides base functionality. You have many devired classes of Animal. You have HomoSapiens, Platypus, Penguin (which extends Bird, another subclass of Animal), Giraffe, Housefly, etc. Each of these are concrete classes that may be instantiated (of course, there are several levels of abstract classes between these and Animal (like Chordata, etc.) Now you want to make something fly. What can fly? Birds and Houseflys (among others), so these classes should provide similar functionality, even though they are widely spaced on our inheritance tree. The solution? Make them use interfaces. Bird and Housefly can not both implement the Flyer interface, so whenever we want something to fly, we can use a Flyer object, not caring whether it's a Bird or a Housefly. Likewise, Penguins and Playtpuses can implement the Swimmer interface (and Penguin should throw an IllegalOperationException in any of its Flyer methods, since Penguins cannot fly). As far as business examples, I have a persistance engine that will work against any data sourcer (XML, ASCII (delimited and fixed-length), various JDBC sources (Oracle, SQL, ODBC, etc.) I created a base, abstract class to provide common functionality in this persistance, but instantiate the appropriate "Port" (subclass) when persisting my objects. (This makes development of new "Ports" much easier, since most of the work is done in the superclasses; especially the various JDBC ones; since I not only do persistance but other things [like table generation], I have to provide the various differences for each database.) The best business examples of Interfaces are the Collections. I can work with a java.util.List without caring how it is implemented; having the List as an abstract class does not make sense because there are fundamental differences in how an ArrayList works as opposed to a LinkedList. Likewise, Map and Set. And if I am just working with a group of objects and don't care if it's a List, Map, or Set, I can just use the Collection interface. Hope that this helps

In my application i use abstract class in make base action class and extend this class in all action class's and interface use in DAO for JDBC and HIBERNATE implementation .

A concrete example of an abstract class would be a class called Animal. You see many animals in real life, but there are only kinds of animals. That is, you never look at something purple and furry and say "that is an animal and there is no more specific way of defining it". Instead, you see a dog or a cat or a pig... all animals. The point is, that you can never see an animal walking around that isn't more specifically something else (duck, pig, etc.). The Animal is the abstract class and Duck/Pig/Cat are all classes that derive from that base class. Animals might provide a function called "Age" that adds 1 year of life to the animals. It might also provide an abstract method called "IsDead" that, when called, will tell you if the animal has died. Since IsDead is abstract, each animal must implement it. So, a Cat might decide it is dead after it reaches 14 years of age, but a Duck might decide it dies after 5 years of age. The abstract class Animal provides the Age function to all classes that derive from it, but each of those classes has to implement IsDead on their own.A business example:I have a persistance engine that will work against any data sourcer (XML, ASCII (delimited and fixed-length), various JDBC sources (Oracle, SQL, ODBC, etc.) I created a base, abstract class to provide common functionality in this persistance, but instantiate the appropriate "Port" (subclass) when persisting my objects. (This makes development of new "Ports" much easier, since most of the work is done in the superclasses; especially the various JDBC ones; since I not only do persistance but other things [like table generation], I have to provide the various differences for each database.) The best business examples of Interfaces are the Collections. I can work with a java.util.List without caring how it is implemented; having the List as an abstract class does not make sense because there are fundamental differences in how anArrayList works as opposed to a LinkedList. Likewise, Map and Set. And if I am just working with a group of objects and don't care if it's a List, Map, or Set, I can just use the Collection interface