What is the main difference between Inheritance and Polymorphism?

What is the main difference between Inheritance and Polymorphism? - java

I was presented with this question in an end of module open book exam today and found myself lost. I was reading Head first Javaand both definitions seemed to be exactly the same. I was just wondering what the MAIN difference was for my own piece of mind. I know there are a number of similar questions to this but, none I have seen which provide a definitive answer.

Inheritance is when a 'class' derives from an existing 'class'. So if you have a Person class, then you have a Student class that extends Person, Student inherits all the things that Person has. There are some details around the access modifiers you put on the fields/methods in Person, but that's the basic idea. For example, if you have a private field on Person, Student won't see it because its private, and private fields are not visible to subclasses.
Polymorphism deals with how the program decides which methods it should use, depending on what type of thing it has. If you have a Person, which has a read method, and you have a Student which extends Person, which has its own implementation of read, which method gets called is determined for you by the runtime, depending if you have a Person or a Student. It gets a bit tricky, but if you do something like
Person p = new Student();
p.read();
the read method on Student gets called. Thats the polymorphism in action. You can do that assignment because a Student is a Person, but the runtime is smart enough to know that the actual type of p is Student.
Note that details differ among languages. You can do inheritance in javascript for example, but its completely different than the way it works in Java.

Inheritance refers to using the structure and behavior of a super class in a subclass.
Polymorphism refers to changing the behavior of a super class in the subclass.

Polymorphism: The ability to treat objects of different types in a similar manner. Example: Giraffe and Crocodile are both Animals, and animals can Move. If you have an instance of an Animal then you can call Move without knowing or caring what type of animal it is.
Inheritance: This is one way of achieving both Polymorphism and code reuse at the same time.
Other forms of polymorphism:
There are other way of achieving polymorphism, such as interfaces, which provide only polymorphism but no code reuse (sometimes the code is quite different, such as Move for a Snake would be quite different from Move for a Dog, in which case an Interface would be the better polymorphic choice in this case.
In other dynamic languages polymorphism can be achieved with Duck Typing, which is the classes don't even need to share the same base class or interface, they just need a method with the same name. Or even more dynamic like Javascript, you don't even need classes at all, just an object with the same method name can be used polymorphically.

The main difference is polymorphism is a specific result of inheritance. Polymorphism is where the method to be invoked is determined at runtime based on the type of the object. This is a situation that results when you have one class inheriting from another and overriding a particular method. However, in a normal inheritance tree, you don't have to override any methods and therefore not all method calls have to be polymorphic. Does that make sense? It's a similar problem to all Ford vehicles are automobiles, but not all automobiles are Fords (although not quite....).
Additionally, polymorphism deals with method invocation whereas inheritance also describes data members, etc.

In Java, the two are closely related. This is because Java uses a technique for method invocation called "dynamic dispatch". If I have
public class A {
public void draw() { ... }
public void spin() { ... }
}
public class B extends A {
public void draw() { ... }
public void bad() { ... }
}
...
A testObject = new B();
testObject.draw(); // calls B's draw, polymorphic
testObject.spin(); // calls A's spin, inherited by B
testObject.bad(); // compiler error, you are manipulating this as an A
Then we see that B inherits spin from A. However, when we try to manipulate the object as if it were a type A, we still get B's behavior for draw. The draw behavior is polymorphic.
In some languages, polymorphism and inheritance aren't quite as closely related. In C++, for example, functions not declared virtual are inherited, but won't be dispatched dynamically, so you won't get that polymorphic behavior even when you use inheritance.
In javascript, every function call is dynamically dispatched and you have weak typing. This means you could have a bunch of unrelated objects, each with their own draw, have a function iterate over them and call the function, and each would behave just fine. You'd have your own polymorphic draw without needing inheritance.

Polymorphism:
Suppose you work for a company that sells pens. So you make a very nice class called "Pen" that handles everything that you need to know about a pen. You write all sorts of classes for billing, shipping, creating invoices, all using the Pen class. A day boss comes and says, "Great news! The company is growing and we are selling Books & CD's now!" Not great news because now you have to change every class that uses Pen to also use Book & CD. But what if you had originally created an interface called "SellableProduct", and Pen implemented this interface. Then you could have written all your shipping, invoicing, etc classes to use that interface instead of Pen. Now all you would have to do is create a new class called Book & CompactDisc which implements the SellableProduct interface. Because of polymorphism, all of the other classes could continue to work without change! Make Sense?
So, it means using Inheritance which is one of the way to achieve polymorphism.
Polymorhism can be possible in a class / interface but Inheritance always between 2 OR more classes / interfaces. Inheritance always conform "is-a" relationship whereas it is not always with Polymorphism (which can conform both "is-a" / "has-a" relationship.

Inheritance is more a static thing (one class extends another) while polymorphism is a dynamic/ runtime thing (an object behaves according to its dynamic/ runtime type not to its static/ declaration type).
E.g.
// This assignment is possible because B extends A
A a = new B();
// polymorphic call/ access
a.foo();
-> Though the static/ declaration type of a is A, the actual dynamic/ runtime type is B and thus a.foo() will execute foo as defined in B not in A.

Polymorphism is an approach to expressing common behavior between types of objects that have similar traits. It also allows for variations of those traits to be created through overriding. Inheritance is a way to achieve polymorphism through an object hierarchy where objects express relationships and abstract behaviors. It isn't the only way to achieve polymorphism though. Prototype is another way to express polymorphism that is different from inheritance. JavaScript is an example of a language that uses prototype. I'd imagine there are other ways too.

Inheritance is a concept related to code reuse. For example if I have a parent class say Animal and it contains certain attributes and methods (for this example say makeNoise() and sleep()) and I create two child classes called Dog and Cat. Since both dogs and cats go to sleep in the same fashion( I would assume) there is no need to add more functionality to the sleep() method in the Dog and Cat subclasses provided by the parent class Animal. However, a Dog barks and a Cat meows so although the Animal class might have a method for making a noise, a dog and a cat make different noises relative to each other and other animals. Thus, there is a need to redefine that behavior for their specific types. Thus the definition of polymorphism. Hope this helps.

Oracle documentation quoted the difference precisely.
inheritance: A class inherits fields and methods from all its superclasses, whether direct or indirect. A subclass can override methods that it inherits, or it can hide fields or methods that it inherits. (Note that hiding fields is generally bad programming practice.)
polymorphism: polymorphism refers to a principle in biology in which an organism or species can have many different forms or stages. This principle can also be applied to object-oriented programming and languages like the Java language. Subclasses of a class can define their own unique behaviors and yet share some of the same functionality of the parent class.
polymorphism is not applicable for fields.
Related post:
Polymorphism vs Overriding vs Overloading

Polymorphism is achieved by Inheritance in Java.
├── Animal
└── (instances)
├── Cat
├── Hamster
├── Lion
└── Moose
├── interface-for-diet
│ ├── Carnivore
│ └── Herbivore
├── interface-for-habitat
│ ├── Pet
│ └── Wild
public class Animal {
void breath() {
};
}
public interface Carnivore {
void loveMeat();
}
public interface Herbivore {
void loveGreens();
}
public interface Pet {
void liveInside();
}
public interface Wild {
void liveOutside();
}
public class Hamster extends Animal implements Herbivore, Pet {
#Override
public void liveInside() {
System.out.println("I live in a cage and my neighbor is a Gerbil");
}
#Override
public void loveGreens() {
System.out.println("I eat Carrots, Grapes, Tomatoes, and More");
}
}
public class Cat extends Animal implements Carnivore, Pet {
#Override
public void liveInside() {
System.out.println("I live in a cage and my neighbr is a Gerbil");
}
#Override
public void loveMeat() {
System.out.println("I eat Tuna, Chicken, and More");
}
}
public class Moose extends Animal implements Herbivore, Wild {
#Override
public void liveOutside() {
System.out.println("I live in the forest");
}
#Override
public void loveGreens() {
System.out.println("I eat grass");
}
}
public class Lion extends Animal implements Carnivore, Wild {
#Override
public void liveOutside() {
System.out.println("I live in the forest");
}
#Override
public void loveMeat() {
System.out.println("I eat Moose");
}
}
Hamster class inherits structure from Animal, Herbivore and Pet to exhibit Polymorphic behaviorism of a domestic pet.
Cat class inherits structure from Animal, Carnivore and Pet to also exhibit Polymorphic behaviorism of a domestic pet.

Polymorphism is an effect of inheritance. It can only happen in classes that extend one another. It allows you to call methods of a class without knowing the exact type of the class. Also, polymorphism does happen at run time.
For example, Java polymorphism example:
Inheritance lets derived classes share interfaces and code of their base classes. It happens at compile time.
For example, All Classes in the Java Platform are Descendants of Object (image courtesy Oracle):
To learn more about Java inheritance and Java polymorphism

If you use JAVA it's as simple as this:
Polymorphism is using inherited methods but "Overriding" them to do something different (or the same if you call super so wouldn't technically be polymorphic).
Correct me if I'm wrong.

The main purpose of polymorphism : To create reference variable to super class and holding the subclass object => an object can perform multiple behaviours.
In inheritance, subclass inherit the properties of super class.

inheritance is kind of polymorphism, Exactly in fact inheritance is the dynamic polymorphism. So, when you remove inheritance you can not override anymore.

With Inheritance the implementation is defined in the superclass -- so the behavior is inherited.
class Animal
{
double location;
void move(double newLocation)
{
location = newLocation;
}
}
class Dog extends Animal;
With Polymorphism the implementation is defined in the subclass -- so only the interface is inherited.
interface Animal
{
void move(double newLocation);
}
class Dog implements Animal
{
double location;
void move(double newLocation)
{
location = newLocation;
}
}

Inheritance leads to polymorphism, and as such both cannot be compared together like would you compare Car and its AC.
If the question is Define Inheritance and Polymorphism in simple terms, then the definitions as picked from Java docs are:
Inheritance : Object-oriented programming allows classes to inherit commonly used state and behaviour from other classes.
Polymorphism : Subclasses of a class can define their own unique behaviours and yet share some of the same functionality of the parent class.

Inheritance is when class A inherits all nonstatic protected/public methods/fields from all its parents till Object.

Related

Is it bad practice to use Inheritance if I plan to override all the methods?

Consider the following two classes:
class A {
String _name;
char _type;
public A(String name, char type) {
_name = name; _type = type;
}
public int method1() {
do_something...;
}
public String method2() {
make_something...;
}
}
and
class B extends A {
public B(String name) {
super(name, 'a');
}
#Override
public int method1() {
do_something_else...;
}
#Override
public String method2() {
String answer = super.method2();
answer += more_processing...;
}
}
I am using inheritance here because the classes share many things in common. However, because I am overriding every single methods from the superclass, is it a good idea to use inheritance here?

That depends on the context. If you are going to use many features of the class (attributes and methods), you must use inheritance and override those few methods you need to change. If you are going to use just few features and need to override almost all methods, you better create a new class. Another case could be if a particular method of the class is very difficult to code or had a very important implementation, again it depends on the context.

Inheritance should be used whenever you can replace an instance of the super-type A with an instance of the sub-type B, without breaking anything. This is also known as the Liskov substitution principle.
Another kind of hacky but still valid case for inheritance is when you need to access otherwise unaccessible methods or properties of the super-type A. In this case, I prefer to not directly let B extend the super-type A but to use an inner class B.ChildOfA that extends the super-type A. This will prevent B from being used as an instance of A where this is not appropriate.
In general, you should prefer composition over inheritance.
To answer your question: It does not depend on whether you overwrite everything but on how your sub-class can or should be used.
If you override everything from A in B and you don't delegate to the super-type A, but both types should still be exchangeable like defined by the Liskov substitution principle, then you also have a third option: You can declare a common super-type I and let both classes inherit it. The newly introduced super-type I can be an interface or a class. Of course, this is only possible if you own the class A, because you need to change it to inherit the new super-type I.

You'll have to ask yourself the question:
Is Class B a subclass of Class A?
Overriding the methods doesn't really matter as long as you understand what inheritance is used for. (i.e Class B is a subtype of Class A but does things a little differently)

The crucial question you have to ask is:
"Is B an A?"
If so, then using inheritance is likely to be a good idea.
Although you may not have any methods that have the same implementation in both classes, that could change in the future as you and others working on your codebase could add new methods.
Another question you have to ask is, does each method and it's overridden version differ by WHAT they do, or just by HOW they behave? If it's the latter then again inheritance is probably the way to go.
Where I work we consider it best practice to mostly use interfaces (composition) over inheritance where possible. This is partly because one class can implement multiple interfaces in Java, but can only extend one class using inheritance. There are other reasons but I don't want to go too off-topic. However if the relationship between the classes you've written is more that they just HAVE similar members, rather than have an "is-a" relationship, then you might want to consider putting those shared members (methods and fields) in an interface instead of using inheritance.

In this case, where B does not actually inherit anything from A it may make more sense to use a common interface that both A and B implement in their own way. Context is important when making these types of inheritance decisions.
public interface SomeInterface {
public int method1();
public String method2();
}
A:
public class A implements SomeInterface {
B:
public class B implements SomeInterface {

Liskov substitution principle and multiple hierarchies

This question is a follow up to this. I am trying to define class heirarchies involving multiple base-derived pairs. As an illustrative example, suppose that I have a class Animal and a class Food. Animal has a pure virtual function to mark its food preference, taking a food as parameter.
class Food
{
public:
virtual void printName() {
//......
}
};
class Animal
{
public:
Food *_preferredFood;
virtual void setFoodPreference(Food *food)=0;
};
I need to write code that deals only with these base classes, and calls the pure virtual function. For example, I have a ZooManager class, which sets food preferences for each animal.
class ZooManager
{
vector<Aninal*> animals;
public:
void setAllPreferences(vector<Food *> foods) {
assert(animals.size() == foods.size());
for(int i =0;i<animals.size();i++) {
animals[i]->setFoodPreference(foods[i]);
}
}
};
So far so good. Now the problem is, that there are many different derived classes for Food and Animal. Food has derived classes Fruit and Meat, and Animal has derived classes Carnivore and Herbivore. Herbivore can accept only Fruit as food preference, and Carnivore can accept only Meat.
class Fruit : public Food
{
};
class Meat : public Food
{
};
class Carnivore: public Animal
{
public:
void setFoodPreference(Food *food) {
this->_preferredFood = dynamic_cast<Meat *>(food);
}
};
class Herbivore: public Animal
{
public:
void setFoodPreference(Food *food) {
this->_preferredFood = dynamic_cast<Fruit *>(food);
}
};
Can I create a class heirarchy for this without violating Liskov Substitution Principle? Although I use C++ in this question, I'd welcome Java-specific answers too.

First, your setFoodPreference has to have the option to fail. That lets setFoodPreference take a Food* and have the postcondition of either setting the food preference, or failing.
The dynamic cast can also be a failure of LSP, but if you arrange your type invariants to be vague enough it isn't technically a failure.
Generally, dynamic_cast means that the type of the argument passed and its properties isn't sufficient to tell if the argument has certain properties.
In principle, setFoodPreference(Food*) should be specified in terms of what Food* properties the passed in argument has to have in order for the setting to be successful; the dynamic type of the Food* is not a Food* property.
So: LSP states that any subclass of Food has to obey all Food invariants. Similarly for Animal. You can avoid a LSP violation by making the invariants vague and the behavior of methods unpredictable; basically by saying "it can fail for unspecified reasons". This is ... not very satisfying.
Now, you can take a step back and decide that the dynamic type of your Food* is part of the Food*'s interface; that makes the interface ridiculously broad, and makes a mockery of LSP.
The point of LSP is that you can reason about a Food* without having to think about its subclass types; they are "how it works as a Food". Your code binds tightly to the subclass types, and thus bypasses the point of LSP.
There are ways around this. If Food had an enum stating what kind of food it was, and you never dynamically cast down to Meat but rather asked the Food if it was meat, you avoid it. Now you can specify setFoodPreference's behavior in terms of Food's interface.

Your approach to designing your hierarchies is wrong. OO classes represent groups of tightly coupled rules, where a rule is a function and tightly coupled means shared data. OO classes do NOT represent real world objects. People are wrong when they say that.
If you are depending on the concrete type of Food, you are violating the Liskov substitution principle. Period.
To design your classes correctly so that you are not forced into violating the LSP as you are here, you need to place rules in the Food class that can be used by the Animal class to accomplish its own rules. Or decide whether Food should even be a class. What your example shows is basically really bad String comparison.

Abstract and Interface Method usage in my Class [duplicate]

What exactly is the difference between an interface and an abstract class?

Interfaces
An interface is a contract: The person writing the interface says, "hey, I accept things looking that way", and the person using the interface says "OK, the class I write looks that way".
An interface is an empty shell. There are only the signatures of the methods, which implies that the methods do not have a body. The interface can't do anything. It's just a pattern.
For example (pseudo code):
// I say all motor vehicles should look like this:
interface MotorVehicle
{
void run();
int getFuel();
}
// My team mate complies and writes vehicle looking that way
class Car implements MotorVehicle
{
int fuel;
void run()
{
print("Wrroooooooom");
}
int getFuel()
{
return this.fuel;
}
}
Implementing an interface consumes very little CPU, because it's not a class, just a bunch of names, and therefore there isn't any expensive look-up to do. It's great when it matters, such as in embedded devices.
Abstract classes
Abstract classes, unlike interfaces, are classes. They are more expensive to use, because there is a look-up to do when you inherit from them.
Abstract classes look a lot like interfaces, but they have something more: You can define a behavior for them. It's more about a person saying, "these classes should look like that, and they have that in common, so fill in the blanks!".
For example:
// I say all motor vehicles should look like this:
abstract class MotorVehicle
{
int fuel;
// They ALL have fuel, so lets implement this for everybody.
int getFuel()
{
return this.fuel;
}
// That can be very different, force them to provide their
// own implementation.
abstract void run();
}
// My teammate complies and writes vehicle looking that way
class Car extends MotorVehicle
{
void run()
{
print("Wrroooooooom");
}
}
Implementation
While abstract classes and interfaces are supposed to be different concepts, the implementations make that statement sometimes untrue. Sometimes, they are not even what you think they are.
In Java, this rule is strongly enforced, while in PHP, interfaces are abstract classes with no method declared.
In Python, abstract classes are more a programming trick you can get from the ABC module and is actually using metaclasses, and therefore classes. And interfaces are more related to duck typing in this language and it's a mix between conventions and special methods that call descriptors (the __method__ methods).
As usual with programming, there is theory, practice, and practice in another language :-)

The key technical differences between an abstract class and an interface are:
Abstract classes can have constants, members, method stubs (methods without a body) and defined methods, whereas interfaces can only have constants and methods stubs.
Methods and members of an abstract class can be defined with any visibility, whereas all methods of an interface must be defined as public (they are defined public by default).
When inheriting an abstract class, a concrete child class must define the abstract methods, whereas an abstract class can extend another abstract class and abstract methods from the parent class don't have to be defined.
Similarly, an interface extending another interface is not responsible for implementing methods from the parent interface. This is because interfaces cannot define any implementation.
A child class can only extend a single class (abstract or concrete), whereas an interface can extend or a class can implement multiple other interfaces.
A child class can define abstract methods with the same or less restrictive visibility, whereas a class implementing an interface must define the methods with the exact same visibility (public).

An Interface contains only the definition / signature of functionality, and if we have some common functionality as well as common signatures, then we need to use an abstract class. By using an abstract class, we can provide behavior as well as functionality both in the same time. Another developer inheriting abstract class can use this functionality easily, as they would only need to fill in the blanks.
Taken from:
http://www.dotnetbull.com/2011/11/difference-between-abstract-class-and.html
http://www.dotnetbull.com/2011/11/what-is-abstract-class-in-c-net.html
http://www.dotnetbull.com/2011/11/what-is-interface-in-c-net.html

An explanation can be found here: http://www.developer.com/lang/php/article.php/3604111/PHP-5-OOP-Interfaces-Abstract-Classes-and-the-Adapter-Pattern.htm
An abstract class is a class that is
only partially implemented by the
programmer. It may contain one or more
abstract methods. An abstract method
is simply a function definition that
serves to tell the programmer that the
method must be implemented in a child
class.
An interface is similar to an abstract
class; indeed interfaces occupy the
same namespace as classes and abstract
classes. For that reason, you cannot
define an interface with the same name
as a class. An interface is a fully
abstract class; none of its methods
are implemented and instead of a class
sub-classing from it, it is said to
implement that interface.
Anyway I find this explanation of interfaces somewhat confusing. A more common definition is: An interface defines a contract that implementing classes must fulfill. An interface definition consists of signatures of public members, without any implementing code.

I don't want to highlight the differences, which have been already said in many answers ( regarding public static final modifiers for variables in interface & support for protected, private methods in abstract classes)
In simple terms, I would like to say:
interface: To implement a contract by multiple unrelated objects
abstract class: To implement the same or different behaviour among multiple related objects
From the Oracle documentation
Consider using abstract classes if :
You want to share code among several closely related classes.
You expect that classes that extend your abstract class have many common methods or fields, or require access modifiers other than public (such as protected and private).
You want to declare non-static or non-final fields.
Consider using interfaces if :
You expect that unrelated classes would implement your interface. For example,many unrelated objects can implement Serializable interface.
You want to specify the behaviour of a particular data type, but not concerned about who implements its behaviour.
You want to take advantage of multiple inheritance of type.
abstract class establishes "is a" relation with concrete classes. interface provides "has a" capability for classes.
If you are looking for Java as programming language, here are a few more updates:
Java 8 has reduced the gap between interface and abstract classes to some extent by providing a default method feature. An interface does not have an implementation for a method is no longer valid now.
Refer to this documentation page for more details.
Have a look at this SE question for code examples to understand better.
How should I have explained the difference between an Interface and an Abstract class?

Some important differences:
In the form of a table:
As stated by Joe from javapapers:
1.Main difference is methods of a Java interface are implicitly abstract and cannot have implementations. A Java abstract class can
have instance methods that implements a default behavior.
2.Variables declared in a Java interface is by default final. An abstract class may contain non-final variables.
3.Members of a Java interface are public by default. A Java abstract class can have the usual flavors of class members like private,
protected, etc..
4.Java interface should be implemented using keyword “implements”; A Java abstract class should be extended using keyword “extends”.
5.An interface can extend another Java interface only, an abstract class can extend another Java class and implement multiple Java
interfaces.
6.A Java class can implement multiple interfaces but it can extend only one abstract class.
7.Interface is absolutely abstract and cannot be instantiated; A Java abstract class also cannot be instantiated, but can be invoked if a
main() exists.
8.In comparison with java abstract classes, java interfaces are slow as it requires extra indirection.

The main point is that:
Abstract is object oriented. It offers the basic data an 'object' should have and/or functions it should be able to do. It is concerned with the object's basic characteristics: what it has and what it can do. Hence objects which inherit from the same abstract class share the basic characteristics (generalization).
Interface is functionality oriented. It defines functionalities an object should have. Regardless what object it is, as long as it can do these functionalities, which are defined in the interface, it's fine. It ignores everything else. An object/class can contain several (groups of) functionalities; hence it is possible for a class to implement multiple interfaces.

When you want to provide polymorphic behaviour in an inheritance hierarchy, use abstract classes.
When you want polymorphic behaviour for classes which are completely unrelated, use an interface.

I am constructing a building of 300 floors
The building's blueprint interface
For example, Servlet(I)
Building constructed up to 200 floors - partially completed---abstract
Partial implementation, for example, generic and HTTP servlet
Building construction completed-concrete
Full implementation, for example, own servlet
Interface
We don't know anything about implementation, just requirements. We can
go for an interface.
Every method is public and abstract by default
It is a 100% pure abstract class
If we declare public we cannot declare private and protected
If we declare abstract we cannot declare final, static, synchronized, strictfp and native
Every interface has public, static and final
Serialization and transient is not applicable, because we can't create an instance for in interface
Non-volatile because it is final
Every variable is static
When we declare a variable inside an interface we need to initialize variables while declaring
Instance and static block not allowed
Abstract
Partial implementation
It has an abstract method. An addition, it uses concrete
No restriction for abstract class method modifiers
No restriction for abstract class variable modifiers
We cannot declare other modifiers except abstract
No restriction to initialize variables
Taken from DurgaJobs Website

Let's work on this question again:
The first thing to let you know is that 1/1 and 1*1 results in the same, but it does not mean that multiplication and division are same. Obviously, they hold some good relationship, but mind you both are different.
I will point out main differences, and the rest have already been explained:
Abstract classes are useful for modeling a class hierarchy. At first glance of any requirement, we are partially clear on what exactly is to be built, but we know what to build. And so your abstract classes are your base classes.
Interfaces are useful for letting other hierarchy or classes to know that what I am capable of doing. And when you say I am capable of something, you must have that capacity. Interfaces will mark it as compulsory for a class to implement the same functionalities.

If you have some common methods that can be used by multiple classes go for abstract classes.
Else if you want the classes to follow some definite blueprint go for interfaces.
Following examples demonstrate this.
Abstract class in Java:
abstract class Animals
{
// They all love to eat. So let's implement them for everybody
void eat()
{
System.out.println("Eating...");
}
// The make different sounds. They will provide their own implementation.
abstract void sound();
}
class Dog extends Animals
{
void sound()
{
System.out.println("Woof Woof");
}
}
class Cat extends Animals
{
void sound()
{
System.out.println("Meoww");
}
}
Following is an implementation of interface in Java:
interface Shape
{
void display();
double area();
}
class Rectangle implements Shape
{
int length, width;
Rectangle(int length, int width)
{
this.length = length;
this.width = width;
}
#Override
public void display()
{
System.out.println("****\n* *\n* *\n****");
}
#Override
public double area()
{
return (double)(length*width);
}
}
class Circle implements Shape
{
double pi = 3.14;
int radius;
Circle(int radius)
{
this.radius = radius;
}
#Override
public void display()
{
System.out.println("O"); // :P
}
#Override
public double area()
{
return (double)((pi*radius*radius)/2);
}
}
Some Important Key points in a nutshell:
The variables declared in Java interface are by default final. Abstract classes can have non-final variables.
The variables declared in Java interface are by default static. Abstract classes can have non-static variables.
Members of a Java interface are public by default. A Java abstract class can have the usual flavors of class members like private, protected, etc..

It's pretty simple actually.
You can think of an interface as a class which is only allowed to have abstract methods and nothing else.
So an interface can only "declare" and not define the behavior you want the class to have.
An abstract class allows you to do both declare (using abstract methods) as well as define (using full method implementations) the behavior you want the class to have.
And a regular class only allows you to define, not declare, the behavior/actions you want the class to have.
One last thing,
In Java, you can implement multiple interfaces, but you can only extend one (Abstract Class or Class)...
This means inheritance of defined behavior is restricted to only allow one per class... ie if you wanted a class that encapsulated behavior from Classes A,B&C you would need to do the following: Class A extends B, Class C extends A .. its a bit of a round about way to have multiple inheritance...
Interfaces on the other hand, you could simply do: interface C implements A, B
So in effect Java supports multiple inheritance only in "declared behavior" ie interfaces, and only single inheritance with defined behavior.. unless you do the round about way I described...
Hopefully that makes sense.

The comparison of interface vs. abstract class is wrong. There should be two other comparisons instead: 1) interface vs. class and 2) abstract vs. final class.
Interface vs Class
Interface is a contract between two objects. E.g., I'm a Postman and you're a Package to deliver. I expect you to know your delivery address. When someone gives me a Package, it has to know its delivery address:
interface Package {
String address();
}
Class is a group of objects that obey the contract. E.g., I'm a box from "Box" group and I obey the contract required by the Postman. At the same time I obey other contracts:
class Box implements Package, Property {
#Override
String address() {
return "5th Street, New York, NY";
}
#Override
Human owner() {
// this method is part of another contract
}
}
Abstract vs Final
Abstract class is a group of incomplete objects. They can't be used, because they miss some parts. E.g., I'm an abstract GPS-aware box - I know how to check my position on the map:
abstract class GpsBox implements Package {
#Override
public abstract String address();
protected Coordinates whereAmI() {
// connect to GPS and return my current position
}
}
This class, if inherited/extended by another class, can be very useful. But by itself - it is useless, since it can't have objects. Abstract classes can be building elements of final classes.
Final class is a group of complete objects, which can be used, but can't be modified. They know exactly how to work and what to do. E.g., I'm a Box that always goes to the address specified during its construction:
final class DirectBox implements Package {
private final String to;
public DirectBox(String addr) {
this.to = addr;
}
#Override
public String address() {
return this.to;
}
}
In most languages, like Java or C++, it is possible to have just a class, neither abstract nor final. Such a class can be inherited and can be instantiated. I don't think this is strictly in line with object-oriented paradigm, though.
Again, comparing interfaces with abstract classes is not correct.

The only difference is that one can participate in multiple inheritance and other cannot.
The definition of an interface has changed over time. Do you think an interface just has method declarations only and are just contracts? What about static final variables and what about default definitions after Java 8?
Interfaces were introduced to Java because of the diamond problem with multiple inheritance and that's what they actually intend to do.
Interfaces are the constructs that were created to get away with the multiple inheritance problem and can have abstract methods, default definitions and static final variables.
See Why does Java allow static final variables in interfaces when they are only intended to be contracts?.

Interface: Turn ( Turn Left, Turn Right.)
Abstract Class: Wheel.
Class: Steering Wheel, derives from Wheel, exposes Interface Turn
One is for categorizing behavior that can be offered across a diverse range of things, the other is for modelling an ontology of things.

In short the differences are the following:
Syntactical Differences Between Interface and Abstract Class:
Methods and members of an abstract class can have any visibility. All methods of an interface must be public. //Does not hold true from Java 9 anymore
A concrete child class of an Abstract Class must define all the abstract methods. An Abstract child class can have abstract methods. An interface extending another interface need not provide default implementation for methods inherited from the parent interface.
A child class can only extend a single class. An interface can extend multiple interfaces. A class can implement multiple interfaces.
A child class can define abstract methods with the same or less restrictive visibility, whereas class implementing an interface must define all interface methods as public.
Abstract Classes can have constructors but not interfaces.
Interfaces from Java 9 have private static methods.
In Interfaces now:
public static - supported
public abstract - supported
public default - supported
private static - supported
private abstract - compile error
private default - compile error
private - supported

Many junior developers make the mistake of thinking of interfaces, abstract and concrete classes as slight variations of the same thing, and choose one of them purely on technical grounds: Do I need multiple inheritance? Do I need some place to put common methods? Do I need to bother with something other than just a concrete class? This is wrong, and hidden in these questions is the main problem: "I". When you write code for yourself, by yourself, you rarely think of other present or future developers working on or with your code.
Interfaces and abstract classes, although apparently similar from a technical point of view, have completely different meanings and purposes.
Summary
An interface defines a contract that some implementation will fulfill for you.
An abstract class provides a default behavior that your implementation can reuse.
Alternative summary
An interface is for defining public APIs
An abstract class is for internal use, and for defining SPIs
On the importance of hiding implementation details
A concrete class does the actual work, in a very specific way. For example, an ArrayList uses a contiguous area of memory to store a list of objects in a compact manner which offers fast random access, iteration, and in-place changes, but is terrible at insertions, deletions, and occasionally even additions; meanwhile, a LinkedList uses double-linked nodes to store a list of objects, which instead offers fast iteration, in-place changes, and insertion/deletion/addition, but is terrible at random access. These two types of lists are optimized for different use cases, and it matters a lot how you're going to use them. When you're trying to squeeze performance out of a list that you're heavily interacting with, and when picking the type of list is up to you, you should carefully pick which one you're instantiating.
On the other hand, high level users of a list don't really care how it is actually implemented, and they should be insulated from these details. Let's imagine that Java didn't expose the List interface, but only had a concrete List class that's actually what LinkedList is right now. All Java developers would have tailored their code to fit the implementation details: avoid random access, add a cache to speed up access, or just reimplement ArrayList on their own, although it would be incompatible with all the other code that actually works with List only. That would be terrible... But now imagine that the Java masters actually realize that a linked list is terrible for most actual use cases, and decided to switch over to an array list for their only List class available. This would affect the performance of every Java program in the world, and people wouldn't be happy about it. And the main culprit is that implementation details were available, and the developers assumed that those details are a permanent contract that they can rely on. This is why it's important to hide implementation details, and only define an abstract contract. This is the purpose of an interface: define what kind of input a method accepts, and what kind of output is expected, without exposing all the guts that would tempt programmers to tweak their code to fit the internal details that might change with any future update.
An abstract class is in the middle between interfaces and concrete classes. It is supposed to help implementations share common or boring code. For example, AbstractCollection provides basic implementations for isEmpty based on size is 0, contains as iterate and compare, addAll as repeated add, and so on. This lets implementations focus on the crucial parts that differentiate between them: how to actually store and retrieve data.
APIs versus SPIs
Interfaces are low-cohesion gateways between different parts of code. They allow libraries to exist and evolve without breaking every library user when something changes internally. It's called Application Programming Interface, not Application Programming Classes. On a smaller scale, they also allow multiple developers to collaborate successfully on large scale projects, by separating different modules through well documented interfaces.
Abstract classes are high-cohesion helpers to be used when implementing an interface, assuming some level of implementation details. Alternatively, abstract classes are used for defining SPIs, Service Provider Interfaces.
The difference between an API and an SPI is subtle, but important: for an API, the focus is on who uses it, and for an SPI the focus is on who implements it.
Adding methods to an API is easy, all existing users of the API will still compile. Adding methods to an SPI is hard, since every service provider (concrete implementation) will have to implement the new methods. If interfaces are used to define an SPI, a provider will have to release a new version whenever the SPI contract changes. If abstract classes are used instead, new methods could either be defined in terms of existing abstract methods, or as empty throw not implemented exception stubs, which will at least allow an older version of a service implementation to still compile and run.
A note on Java 8 and default methods
Although Java 8 introduced default methods for interfaces, which makes the line between interfaces and abstract classes even blurrier, this wasn't so that implementations can reuse code, but to make it easier to change interfaces that serve both as an API and as an SPI (or are wrongly used for defining SPIs instead of abstract classes).
Which one to use?
Is the thing supposed to be publicly used by other parts of the code, or by other external code? Add an interface to it to hide the implementation details from the public abstract contract, which is the general behavior of the thing.
Is the thing something that's supposed to have multiple implementations with a lot of code in common? Make both an interface and an abstract, incomplete implementation.
Is there ever going to be only one implementation, and nobody else will use it? Just make it a concrete class.
"ever" is long time, you could play it safe and still add an interface on top of it.
A corollary: the other way around is often wrongly done: when using a thing, always try to use the most generic class/interface that you actually need. In other words, don't declare your variables as ArrayList theList = new ArrayList(), unless you actually have a very strong dependency on it being an array list, and no other type of list would cut it for you. Use List theList = new ArrayList instead, or even Collection theCollection = new ArrayList if the fact that it's a list, and not any other type of collection doesn't actually matter.

Not really the answer to the original question, but once you have the answer to the difference between them, you will enter the when-to-use-each dilemma:
When to use interfaces or abstract classes? When to use both?
I've limited knowledge of OOP, but seeing interfaces as an equivalent of an adjective in grammar has worked for me until now (correct me if this method is bogus!). For example, interface names are like attributes or capabilities you can give to a class, and a class can have many of them: ISerializable, ICountable, IList, ICacheable, IHappy, ...

You can find clear difference between interface and abstract class.
Interface
Interface only contains abstract methods.
Force users to implement all methods when implements the interface.
Contains only final and static variables.
Declare using interface keyword.
All methods of an interface must be defined as public.
An interface can extend or a class can implement multiple other
interfaces.
Abstract class
Abstract class contains abstract and non-abstract methods.
Does not force users to implement all methods when inherited the
abstract class.
Contains all kinds of variables including primitive and non-primitive
Declare using abstract keyword.
Methods and members of an abstract class can be defined with any
visibility.
A child class can only extend a single class (abstract or concrete).

I am 10 yrs late to the party but would like to attempt any way. Wrote a post about the same on medium few days back. Thought of posting it here.
tl;dr; When you see “Is A” relationship use inheritance/abstract class. when you see “has a” relationship create member variables. When you see “relies on external provider” implement (not inherit) an interface.
Interview Question: What is the difference between an interface and an abstract class? And how do you decide when to use what?
I mostly get one or all of the below answers:
Answer 1: You cannot create an object of abstract class and interfaces.
ZK (That’s my initials): You cannot create an object of either. So this is not a difference. This is a similarity between an interface and an abstract class. Counter
Question: Why can’t you create an object of abstract class or interface?
Answer 2: Abstract classes can have a function body as partial/default implementation.
ZK: Counter Question: So if I change it to a pure abstract class, marking all the virtual functions as abstract and provide no default implementation for any virtual function. Would that make abstract classes and interfaces the same? And could they be used interchangeably after that?
Answer 3: Interfaces allow multi-inheritance and abstract classes don’t.
ZK: Counter Question: Do you really inherit from an interface? or do you just implement an interface and, inherit from an abstract class? What’s the difference between implementing and inheriting?
These counter questions throw candidates off and make most scratch their heads or just pass to the next question. That makes me think people need help with these basic building blocks of Object-Oriented Programming.
The answer to the original question and all the counter questions is found in the English language and the UML.
You must know at least below to understand these two constructs better.
Common Noun: A common noun is a name given “in common” to things of the same class or kind. For e.g. fruits, animals, city, car etc.
Proper Noun: A proper noun is the name of an object, place or thing. Apple, Cat, New York, Honda Accord etc.
Car is a Common Noun. And Honda Accord is a Proper Noun, and probably a Composit Proper noun, a proper noun made using two nouns.
Coming to the UML Part. You should be familiar with below relationships:
Is A
Has A
Uses
Let’s consider the below two sentences.
- HondaAccord Is A Car?
- HondaAccord Has A Car?
Which one sounds correct? Plain English and comprehension. HondaAccord and Cars share an “Is A” relationship. Honda accord doesn’t have a car in it. It “is a” car. Honda Accord “has a” music player in it.
When two entities share the “Is A” relationship it’s a better candidate for inheritance. And Has a relationship is a better candidate for creating member variables.
With this established our code looks like this:
abstract class Car
{
string color;
int speed;
}
class HondaAccord : Car
{
MusicPlayer musicPlayer;
}
Now Honda doesn't manufacture music players. Or at least it’s not their main business.
So they reach out to other companies and sign a contract. If you receive power here and the output signal on these two wires it’ll play just fine on these speakers.
This makes Music Player a perfect candidate for an interface. You don’t care who provides support for it as long as the connections work just fine.
You can replace the MusicPlayer of LG with Sony or the other way. And it won’t change a thing in Honda Accord.
Why can’t you create an object of abstract classes?
Because you can’t walk into a showroom and say give me a car. You’ll have to provide a proper noun. What car? Probably a honda accord. And that’s when a sales agent could get you something.
Why can’t you create an object of an interface?
Because you can’t walk into a showroom and say give me a contract of music player. It won’t help. Interfaces sit between consumers and providers just to facilitate an agreement. What will you do with a copy of the agreement? It won’t play music.
Why do interfaces allow multiple inheritance?
Interfaces are not inherited. Interfaces are implemented.
The interface is a candidate for interaction with the external world.
Honda Accord has an interface for refueling. It has interfaces for inflating tires. And the same hose that is used to inflate a football. So the new code will look like below:
abstract class Car
{
string color;
int speed;
}
class HondaAccord : Car, IInflateAir, IRefueling
{
MusicPlayer musicPlayer;
}
And the English will read like this “Honda Accord is a Car that supports inflating tire and refueling”.

Key Points:
Abstract class can have property, Data fields ,Methods (complete /
incomplete) both.
If method or Properties define in abstract keyword that must override in derived class.(its work as a tightly coupled
functionality)
If define abstract keyword for method or properties in abstract class you can not define body of method and get/set value for
properties and that must override in derived class.
Abstract class does not support multiple inheritance.
Abstract class contains Constructors.
An abstract class can contain access modifiers for the subs, functions, properties.
Only Complete Member of abstract class can be Static.
An interface can inherit from another interface only and cannot inherit from an abstract class, where as an abstract class can inherit from another abstract class or another interface.
Advantage:
It is a kind of contract that forces all the subclasses to carry on the same hierarchies or standards.
If various implementations are of the same kind and use common behavior or status then abstract class is better to use.
If we add a new method to an abstract class then we have the option of providing default implementation and therefore all the existing code might work properly.
Its allow fast execution than interface.(interface Requires more time to find the actual method in the corresponding classes.)
It can use for tight and loosely coupling.
find details here...
http://pradeepatkari.wordpress.com/2014/11/20/interface-and-abstract-class-in-c-oops/

The shortest way to sum it up is that an interface is:
Fully abstract, apart from default and static methods; while it has definitions (method signatures + implementations) for default and static methods, it only has declarations (method signatures) for other methods.
Subject to laxer rules than classes (a class can implement multiple interfaces, and an interface can inherit from multiple interfaces). All variables are implicitly constant, whether specified as public static final or not. All members are implicitly public, whether specified as such or not.
Generally used as a guarantee that the implementing class will have the specified features and/or be compatible with any other class which implements the same interface.
Meanwhile, an abstract class is:
Anywhere from fully abstract to fully implemented, with a tendency to have one or more abstract methods. Can contain both declarations and definitions, with declarations marked as abstract.
A full-fledged class, and subject to the rules that govern other classes (can only inherit from one class), on the condition that it cannot be instantiated (because there's no guarantee that it's fully implemented). Can have non-constant member variables. Can implement member access control, restricting members as protected, private, or private package (unspecified).
Generally used either to provide as much of the implementation as can be shared by multiple subclasses, or to provide as much of the implementation as the programmer is able to supply.
Or, if we want to boil it all down to a single sentence: An interface is what the implementing class has, but an abstract class is what the subclass is.

Inheritance is used for two purposes:
To allow an object to regard parent-type data members and method implementations as its own.
To allow a reference to an objects of one type to be used by code which expects a reference to supertype object.
In languages/frameworks which support generalized multiple inheritance, there is often little need to classify a type as either being an "interface" or an "abstract class". Popular languages and frameworks, however, will allow a type to regard one other type's data members or method implementations as its own even though they allow a type to be substitutable for an arbitrary number of other types.
Abstract classes may have data members and method implementations, but can only be inherited by classes which don't inherit from any other classes. Interfaces put almost no restrictions on the types which implement them, but cannot include any data members or method implementations.
There are times when it's useful for types to be substitutable for many different things; there are other times when it's useful for objects to regard parent-type data members and method implementations as their own. Making a distinction between interfaces and abstract classes allows each of those abilities to be used in cases where it is most relevant.

Differences between abstract class and interface on behalf of real implementation.
Interface: It is a keyword and it is used to define the template or blue print of an object and it forces all the sub classes would follow the same prototype,as for as implementation, all the sub classes are free to implement the functionality as per it's requirement.
Some of other use cases where we should use interface.
Communication between two external objects(Third party integration in our application) done through Interface here Interface works as Contract.
Abstract Class: Abstract,it is a keyword and when we use this keyword before any class then it becomes abstract class.It is mainly used when we need to define the template as well as some default functionality of an object that is followed by all the sub classes and this way it removes the redundant code and one more use cases where we can use abstract class, such as we want no other classes can directly instantiate an object of the class, only derived classes can use the functionality.
Example of Abstract Class:
public abstract class DesireCar
{
//It is an abstract method that defines the prototype.
public abstract void Color();
// It is a default implementation of a Wheel method as all the desire cars have the same no. of wheels.
// and hence no need to define this in all the sub classes in this way it saves the code duplicasy
public void Wheel() {
Console.WriteLine("Car has four wheel");
}
}
**Here is the sub classes:**
public class DesireCar1 : DesireCar
{
public override void Color()
{
Console.WriteLine("This is a red color Desire car");
}
}
public class DesireCar2 : DesireCar
{
public override void Color()
{
Console.WriteLine("This is a red white Desire car");
}
}
Example Of Interface:
public interface IShape
{
// Defines the prototype(template)
void Draw();
}
// All the sub classes follow the same template but implementation can be different.
public class Circle : IShape
{
public void Draw()
{
Console.WriteLine("This is a Circle");
}
}
public class Rectangle : IShape
{
public void Draw()
{
Console.WriteLine("This is a Rectangle");
}
}

I'd like to add one more difference which makes sense.
For example, you have a framework with thousands of lines of code. Now if you want to add a new feature throughout the code using a method enhanceUI(), then it's better to add that method in abstract class rather in interface. Because, if you add this method in an interface then you should implement it in all the implemented class but it's not the case if you add the method in abstract class.

To give a simple but clear answer, it helps to set the context : you use both when you do not want to provide full implementations.
The main difference then is an interface has no implementation at all (only methods without a body) while abstract classes can have members and methods with a body as well, i.e. can be partially implemented.

usually Abstract class used for core of something but interface used for appending peripheral.
when you want to create base type for vehicle you should use abstract class but if you want to add some functionality or property that is not part of base concept of vehicle you should use interface,for example you want to add "ToJSON()" function.
interface has wide range of abstraction rather than abstract class.
you can see this in passing arguments.look this example:
if you use vehicle as argument you just can use one of its derived type (bus or car-same category-just vehicle category).
but when you use IMoveable interface as argument you have more choices.

The topic of abstract classes vs interfaces is mostly about semantics.
Abstract classes act in different programming languages often as a superset of interfaces, except one thing and that is, that you can implement multiple interfaces, but inherit only one class.
An interface defines what something must be able to do; like a contract, but does not provide an implementation of it.
An abstract class defines what something is and it commonly hosts shared code between the subclasses.
For example a Formatter should be able to format() something. The common semantics to describe something like that would be to create an interface IFormatter with a declaration of format() that acts like a contract. But IFormatter does not describe what something is, but just what it should be able to to. The common semantics to describe what something actually is, is to create a class. In this case we create an abstract class... So we create an abstract class Formatter which implements the interface. That is a very descriptive code, because we now know we have a Formatter and we now know what every Formatter must be able to do.
Also one very important topic is documentation (at least for some people...). In your documentation you probably want to explain within your subclasses what a Formatter actually is. It is very convenient to have an abstract class Formatter to which documentation you can link to within your subclasses. That is very convenient and generic. On the other hand if you do not have an abstract class Formatter and only an interface IFormatter you would have to explain in each of your subclasses what a Formatter actucally is, because an interface is a contract and you would not describe what a Formatter actually is within the documentation of an interface — at least it would be not something common to do and you would break the semantics that most developers consider to be correct.
Note: It is a very common pattern to make an abstract class implement an interface.

An abstract class is a class whose object cannot be created or a class which cannot be instantiated.
An abstract method makes a class abstract.
An abstract class needs to be inherited in order to override the methods that are declared in the abstract class.
No restriction on access specifiers.
An abstract class can have constructor and other concrete(non abstarct methods ) methods in them but interface cannot have.
An interface is a blueprint/template of methods.(eg. A house on a paper is given(interface house) and different architects will use their ideas to build it(the classes of architects implementing the house interface) .
It is a collection of abstract methods , default methods , static methods , final variables and nested classes.
All members will be either final or public , protected and private access specifiers are not allowed.No object creation is allowed.
A class has to be made in order to use the implementing interface and also to override the abstract method declared in the interface. An interface is a good example of loose coupling(dynamic polymorphism/dynamic binding)
An interface implements polymorphism and abstraction.It tells what to do but how to do is defined by the implementing class.
For Eg. There's a car company and it wants that some features to be same for all the car it is manufacturing so for that the company would be making an interface vehicle which will have those features and different classes of car(like Maruti Suzkhi , Maruti 800) will override those features(functions).
Why interface when we already have abstract class?
Java supports only multilevel and hierarchal inheritance but with the help of interface we can implement multiple inheritance.

In an interface all methods must be only definitions, not single one should be implemented.
But in an abstract class there must an abstract method with only definition, but other methods can be also in the abstract class with implementation...

Why are interfaces helpful?

I know exactly what are the differences between Interfaces and Abstract classes, but why are Interfaces helpful? look at this :

Now imagine abstractions Point and Circle. How would you achieve that a MovablePoint is both Movable and Point? Only interfaces can give you that, and that's what they are here for.

see HERE
An abstract class is good if you think you will plan on using inheritance since it provides a common base class implementation to
derived classes.
An abstract class is also good if you want to be able to declare non-public members. In an interface, all methods must be public.
If you think you will need to add methods in the future, then an abstract class is a better choice. Because if you add new method
headings to an interface, then all of the classes that already
implement that interface will have to be changed to implement the new
methods. That can be quite a hassle.
Interfaces are a good choice when you think that the API will not change for a while.
Interfaces are also good when you want to have something similar to multiple inheritance, since you can implement multiple interfaces.
SO in your scenario only with interfaces you can specify if a MovablePoint is both Movable and Point.

Yes--in this instance you could have, but try looking at the bigger picture, too. I asked the same question when I first learning OOP and interfaces confused me for a long time.
What if you wanted to add the 'movable' methods to an object that wasn't a subclass of Point, let's say 'MovableJPEG' or some such thing. The end result of the move actions would be the same, but you'd have to rewrite the interface for both classes and different methods to handle moving these features around in classes that interacted with Movable objects.
With an interface you pass a any number of Types related only by having a similar interface to the same method because their implementation details are guaranteed to be the same.

Both interfaces and abstract classes allow a programmer to write modular classes.
The advantage of an interface over an abstract class is that it does not carry any predefined methods or properties with it. An abstract class may have things that you do not want implemented inside of your class.
A second advantage is that a java class can only extend one class, but a large number of interfaces.
Interfaces provide more freedom, where an abstract class can influence the internal design of a class. One advantage of an abstract class is code sharing, which is more difficult with interfaces.

you do not have multiple inheritance in java. so multiple classes cant be inherited in same class but multiple interfaces can be implemented
helps in keeping things organized. Like all the things related to DOG is under one interface, all CATs under CAT and so on.
Runtime polymorphisim : with interface u can have superclass reference variable referring different different sub classes. This helps in keeping code clean, improves scalability ( makes possible all those bridge/proxy/factory etc design patterns which otherwise might not have been there).

Imagine someone using your library wants to introduce something other usable, such as a MovableTirangle. If they let this implement Movable, it can be perfectly used with your library.
For example, the library provides a
void move(Movable m, int horiz, int vert) {
int i;
if (horiz >= 0) {
for (i=0; i < horiz; i++) {
m.moveRight();
}
} else {
for (i=0; i > horiz; i--) {
m.moveLeft();
}
}
if (vert >= 0) {
for (i=0; i < vert; i++) {
m.moveUp();
}
} else {
for (i=0; i > vert; i--) {
m.moveDown();
}
}
}
which can be used with all current and future kinds of Movables.
Until now, this is valid for base classes as well, so that doesn't really count.
But, as Java doesn't support multiple inheritance, a class cannot inherit from more than one base class. But it can implement more than one interface, if this should be needed.
Besides, if you had a functional interface (which you haven't, because you have more than one non-default function in it), you could additionally make use of the new lambda feature of Java. That's another thing which doesn't work with abstract classes.

Let you are trying to give as set of similar property to some unrelated classes. Then you may use interface. For example -
<Bounceable>
/ \
Ball Tire
Here Ball and Tire (of a car) are totally unrelated. But both of them are Bounceable. If you want two unrelated class to have the same property then you can use interface.
There is another important use of interface - giving the flavor of multiple inheritance but with more efficiently than multiple inheritance (where there is a common Deadly Diamond of Death problem.). For example you are expecting a Ball should be both Bouncable and Serializeable. Here Bouncable and Serializeable are totally unrelated of each other. Then you can use interface here. Abstract class need to be extended/inherited and in java multiple inheritance is not possible. So we can provide completely unrelated property to a class by using interface.

Conceptual Difference:
I will not list all the differences between using interfaces or abstract classes or when to use each of them, I think you will find a lot of resources in the web and SO talking only about that, as an example: How should I have explained the difference between an Interface and an Abstract class?
To answer you, Yes, you can use only abstract class in your example and you don't have to use an interface
But, there is a Conceptual Difference, Interfaces are not created to expose public behavior, it's a contract for what a class can do.
While abstract classes are parent of a hierarchy to produce children having core structure and providing default behavior.
Analogy with your example:
Conceptually, Movable must be an Interface because it defines what a class that implements Movable can do (can move up, move down, move...) and not how to do it (Circle dosn't move like Rectangle). While your MovableCircle could be an abstract class because we can define methods like : calculateArea(), getRadius(), calculateCircumference(), ... Which is a default behavior for classes that will inherit from it like MovableWheel.
.

IMO while it's correct when people explain interface as a contract i.e. an obligation to implement method signature, i find that they often forget to mention the use of interface as type for the whole group of objects that implement that same interface, and i believe that to be important piece of the puzzle, understanding the usefulness of interface.
Here is a code example (C#) with Cat and Dog classes that uses both interface and absctract class, which hopefully should higlight differences between them.
Assumption 1: both animals say sounds, but these are different sounds (different methods needed)
Assumption 2: both animals can eat, if they are not full (here one method is needed for both animals)
static void Main(string[] args)
{
IanimalBehavior pluto = new Dog();
IanimalBehavior simba = new Cat();
Program.makeAnimals_say_and_eat(pluto);
Program.makeAnimals_say_and_eat(simba);
Program.makeAnimals_say_and_eat(pluto);
Program.makeAnimals_say_and_eat(simba);
Console.ReadLine();
}
static void makeAnimals_say_and_eat(IanimalBehavior animalObject)
{
Console.WriteLine(animalObject.makeSound());
Console.WriteLine(animalObject.eat());
}
interface IanimalBehavior {
string makeSound();
string eat();
}
class Dog : Animal, IanimalBehavior {
public string makeSound() {
return this.GetType().Name + " says: wuf";
}
}
class Cat : Animal, IanimalBehavior {
public string makeSound()
{
return this.GetType().Name + " says: miauw";
}
}
abstract class Animal {
bool _isFull = false;
public string eat()
{
if (_isFull == false)
{
_isFull = true;
return this.GetType().Name + " is now eating";
}
else
{
return this.GetType().Name + " is now too full to eat!";
}
}
}
Notice that animals are declared as interface types:
IanimalBehavior pluto = new Dog();
This will ensure that the method makeAnimals_say_and_eat() can take a parameter type that targets both types of objects (Cat & Dog), so only one method is needed for all animals which is what we want.
static void makeAnimals_say_and_eat(IanimalBehavior animalObject)
{
Console.WriteLine(animalObject.makeSound());
Console.WriteLine(animalObject.eat());
}
The method calls .makeSound() and .eat() from any object that is passed as parameter. Compiler is happy because it knows that any IanimalBehavior type must include both methods because it says so in the contract:
interface IanimalBehavior {
string makeSound();
string eat();
}
on .makeSound() the return value depends on the class type while .eat() is the same for both classes because eat() is declared in absctract class Animal that all animals inherit from.
the ouput of these instructions:
Program.makeAnimals_say_and_eat(pluto);
Program.makeAnimals_say_and_eat(simba);
Program.makeAnimals_say_and_eat(pluto);
Program.makeAnimals_say_and_eat(simba);
are:
Dog says: wuf
Dog is now eating
Cat says: miauw
Cat is now eating
Dog says: wuf
Dog is now too full to eat!
Cat says: miauw
Cat is now too full to eat!
Interface types also gives you the option of storing different objects of similar nature (same interface implemetation) in a single array which you then can iterate.
IanimalBehavior[] animal_list = { new Dog(), new Cat()};
foreach (IanimalBehavior animal in animal_list)
{
Console.WriteLine(animal.eat());
Console.WriteLine(animal.makeSound());
}

Why not override instead of using abstract class?

This might be a simple question for many but has confused me. I am picking an example from Kathy Sierra that shows the utility of Abstract Classes but I am unable to understand the overall importance of abstract classes.
Example
We have an abstract class Car with abstract methods - power() & topSpeed(). These methods are implemented in sub classes BMW, Volkswagen and Audi.
My question is - why do we need to have the abstract class Car in the first place to customize methods for each car type? Why not have these two methods in any one of these car subtypes, say BMW and then other two - Volkswagen and Audi - can simply override these methods?

By making a method abstract, it means that people have to implement it. You require people to do so and it is impossible for people to forget to do so, as it will fail to compile if they do.
The #override annotation exists for a very similar reason, by marking a method as #override you get an error if (for example) you typed the method name wrong and aren't actually overriding something.
In many ways the abstract class is half way between an interface and a normal class - it defines what you need to do to use it in the same way an interface does, but it also handles some of the implementation for you.
Classes can only extend one other class. They can implement any number of interfaces.
For example you might have MotorVehicle inherited by Car, Motorbike and Train - but then you might have a Steerable interface implemented by Car, Motorbike and Pedalbike.
To answer the question in the comments:
If there is an Interface "I" having method m() which is implemented by class "A" and another class "B" wants to access the method m(), what is the need of interface here. Can we simply not implement that method in class A?
You can - but if on the other hand class B wants to access the method m() in both a class A and class C (where A and C don't inherit from each other or a common class containing m()) then the way to do that is to specify a common interface I and class B uses the interface type, I, not the types A and C at all.
Also remember that interfaces can be used between packages and libraries. For example Listener and Strategy patterns make heavy use of interfaces. When the Java developers wrote JButton (for example) the ActionLstener is specified as an Interface to provide maximum flexibility to people using JButtons in the future.

Why not have these two methods in any one of these car subtypes, say BMW and then other two - Volkswagen and Audi - can simply override these methods?
Wouldn't that require Volkswagen and Audi to inherit from BMW? That wouldn't be correct, since those aren't BMWs.
The abstract base class and its abstract methods form a kind of contract which inheriting objects must implement. There's no such thing as a concrete Car that isn't a more specific type. But all concrete types share commonalities. The abstract Car enforces those commonalities, allowing specific types to be treated as generic instances of Car when needed.
For example, if you have code which needs a Car on which it will invoke the Drive() method, that code doesn't care what kind of Car it gets. It will Drive() any Car. So it accepts an abstract type so that anything which implements that type can be used:
UseACar(Car car)
{
car.Drive();
}
// elsewhere
BMW myCar = new BMW();
UseACar(myCar);
Without this enforcement of the contract, a statically-typed and compiled language would have no way of guaranteeing that .Drive() exists on the object. You'd need to create a UseAX() method for every possible kind of car, each accepting a different type. Using polymorphism like this allows you to create a single, more generic method which works on any instance of the abstract type.

So that you can write code that deals with Cars without knowing what kind of car it is:
public void PrintTopSpeed(Car car)
{
System.out.println("This car's top speed is " + car.topSpeed());
}
If the Car class didn't define topSpeed(), this code wouldn't compile. You'd have to have a different version of this print function for each of your BMW, Volkswagen, Audi, etc. derived classes. This is perhaps the most basic concept in object-oriented programming, so you really need to master it. Base classes allow objects to share common behavior, and allow code to be written to use that behavior without any knowledge of what specific type of object it's dealing with.

Polymorphism is the answer. If you don't have methods power() and topSpeed() in the abstract class you can't do things like this :
List<Car> cars;
cars.add(new Porshe());
cars.add(new Ford());
for(Car car : cars){
System.out.println(car.topSpeed());
}
You would have to handle lot of thing your self if you have only custom methods in your subclasses.

This is called abstraction. Methods in abstract class are considered as protocol so that car makers should not violate.

abstraction is great when the original programmer/architect want's to allow customized behavior to some base class and ensure that the consuming programmer implements the required methods.

Develop Reference

Java is a programming language and computing platform first released by Sun Microsystems in 1995.