abstract vs interface and need realtime scenario example

[java..]

i know the difference between interface and abstract.

how it will differ in real-time application scenario.

can you please explain with example?

[jon.kiparsky]

An interface is a contract between you and the compiler. The compiler will allow that your class will stand in for an X if you implement the X interface and provide all of the methods that interface demands.

An abstract class is an actual class which you can extend, but which cannot be instantiated itself. It will typically have some collection of methods, some of which may be abstract, meaning they have no code in them, and others of which may have code. You must override the abstract methods (although it may be with empty methods if you like), and you may also override the non-abstract methods as well.

An interface is usually for providing some specific functionality: if this class implements "Comparable", it is sensible to compare it, and I have told you how to do that. We know nothing about the class at this point other than that I have told you how to tell whether this one is greater than, less than, or equal to this other one. If it's "Comparable" it might also be "Printable", or it might not.

An abstract class is typically used to define a "sort of thing" - a high-level notion of a type of object. The classic example is "Animal". "Animal" would probably be an abstract class, since there are things that all animals do, but for the most part all animals do them in different ways. You might have abstract methods like "eat(Comestible c)" and "breathe()" and "reproduce()" but since animals include baboons and blowfish and bedbugs and bowerbirds, each of those methods would have to be implemented in different ways for each of those animals. You might inherit down to "Mammal" and "Fish" and "Bird", and make those abstract as well. By the time you get down to "Llama" you're looking at concrete classes, which can be instantiated.
So in this model, you can't have particular instances of "Mammal", you can only have particular instances of "Llama" or "Baboon". However, you might have a List<Mammal> which can contain Llamas and Baboons and Tigers (oh my!) - but no fishes.

This is an important question, and you'll get a few answers to it, some in terms of metaphors (as I've done, mostly) and some in terms of bare-metal machine logic. Understanding this difference is an important step in understanding object-oriented design.

[java..]

jon.kiparsky@:thank you for your valuable reply.

what are the OOPS concept comes into play for in terms of abstract and interface

[jon.kiparsky]

Briefly (hah!), abstract classes are part of the inheritance mechanism, which is critical to OO programming. Objects inherit functionality, which allows you to code that functionality once, rather than rewriting it each time it's needed. Inheritance also allows you to specialize objects while retaining their essential similarity.

Here's a real-life example. Imagine a program using the following classes:
ModelElement (abstract)
Connection extends modelElement
Node (abstract) extends modelElement
EmptyNode extends Node
OrganismNode extends Node

You don't need to know what these actually do or what they're used for (I can point you to the code, if you're curious) but you can already guess that they're probably used in modelling some sort of system consisting of two types of Nodes, which are linked by Connections. You can guess (correctly) that there's a Model which contains ModelElements, and that it's likely got something from the Collections framework at its core, and its parameterized type is <ModelElement> (it's an ArrayList, in fact). You can imagine that ModelElement has very little functional code, but that Node might have some concrete methods to do the things that both sorts of nodes would have to do, and that there are some further specialized things that each sort of Node can do.

All of this is done by inheritance. Allowing abstract classes makes inheriance easier to handle, by allowing you to specify classes which won't actually be instantiated - ideas, that is. Nobody ever drives a Vehicle, they don't even drive a StationWagon, they drive an instance of VolvoM500, or whatever Volvo's model numbers look like.

Interfaces, on the other hand, do not have anything to do with inheritance. They simply allow you to guarantee to the compiler that your class has, among others, a certain set of methods with a certain set of signatures. You don't get any of the functionality from the interface, because it doesn't specify any - it's not allowed to. If you say that your class implements Comparable, all you're saying is that you have a CompareTo() method that takes another instance of the class as an argument and returns an int. If you want this to be useful, you'll return a zero if they're equal, etc., but you don't have to - you can return random numbers, in principle.

This allows you to abstract away everything about an object but the functionality you care about. I don't care what I'm sorting, all I care about is that you can tell me whether this one goes before or after the other one.

So you see, the two are actually quite complementary notions. One asserts a sort of membership in a group, in a hierarchy, while the other asserts a glorious unconcern for an object's identity, looking only at its abilities. This starts to sound like sociology, when I put it that way, so perhaps I should stop here. :)