Interfaces and Abstract classes confusion in Java with examples - java

I'm having trouble understanding when to use an interface as opposed to an abstract class and vice versa. Also, I am confused when to extend an interface with another interface. Sorry about the long post, but this is very confusing.
Creating shapes seems like a popular starting point. Let's say we want a way to model 2D shapes. We know that each shape will have an area. What would be the difference between the following two implementations:
with interfaces:
public interface Shape {
public double area();
}
public class Square implements Shape{
private int length = 5;
public Square(){...}
public double area()
return length * length;
}
}
with abstract class:
abstract class Shape {
abstract public double area();
}
public class Square extends Shape {
private length = 5;
public Square(){...}
public double area(){
return length * length;
}
I understand that abstract classes allows you to define instance variables and allows you to give method implementations whereas an interface cannot do these things. But in this case, it seems like these two implementations are identical. So using any one is fine?
But now say we want to describe different types of triangles. We can have an isosceles, acute, and right angle triangles. To me, it makes sense to use class inheritance in this case. Using the 'IS-A' definition: a Right Triangle "IS-A" Triangle. A Triangle "IS-A" Shape. Also, an abstract class should define behaviors and attributes that are common within all subclasses, so this is perfect:
with abstract class
abstract Triangle extends Shape {
private final int sides = 3;
}
class RightTriangle extends Triangle {
private int base = 4;
private int height = 5;
public RightTriangle(){...}
public double area() {
return .5 * base * height
}
}
We can do this with interfaces as well, with Triangle and Shape being interfaces. However, unlike class inheritance (using 'IS-A' relationship to define what should be a subclass), I'm not sure how to use an interface. I see two ways:
First way:
public interface Triangle {
public final int sides = 3;
}
public class RightTriangle implements Triangle, Shape {
private int base = 4;
private int height = 5;
public RightTriangle(){}
public double area(){
return .5 * height * base;
}
}
Second way:
public interface Triangle extends Shape {
public final int sides = 3;
}
public class RightTriangle implements Triangle {
....
public double area(){
return .5 * height * base;
}
}
It seems to me like both of these ways work. But when would you use one way over the other? And are there any advantages to using interfaces over abstract classes to represent different triangles? Even though we complicated the description of a shape, using interface vs abstract class still seem equivalent.
A critical component to interfaces is that it can define behaviors that can be shared across unrelated classes. So an interface Flyable would be present in classes Airplane as well as in Bird. So in this case, it is clear that an interface approach is preferred.
Also, to build off of the confusing interface extending another interface:
When should the 'IS-A' relationship be ignored when deciding on what should be an interface?
Take this example: LINK.
Why should 'VeryBadVampire' be a class and 'Vampire' be an interface? A 'VeryBadVampire' IS-A 'Vampire', so my understanding is that a 'Vampire' should be a superclass (maybe abstract class). A 'Vampire' class can implement 'Lethal' to keep its lethal behavior. Furthermore, a 'Vampire' IS-A 'Monster', so 'Monster' should be a class as well. A 'Vampire' class can also implement an interface called 'Dangerous' to keep its dangerous behavior. If we wish to create a new monster called 'BigRat' which is dangerous but not lethal, then we can create a 'BigRat' class which extends 'Monster' and implements 'Dangerous'.
Wouldn't the above achieve the same output as using 'Vampire' as an interface (described in the link)? The only difference I see is that using class inheritance and preserving the 'IS-A' relationship clears up a lot of confusion. Yet this is not followed. What is the advantage of doing this?
Even if you wanted a monster to share vampiric behavior, one can always redefine how the objects are represented. If we wanted a new type of vampire monster called 'VeryMildVampire' and we wanted to create a vampire-like monster called 'Chupacabra', we can do this:
'Vampire' class extends 'Monster' implements 'Dangerous', 'Lethal', 'BloodSuckable'
'VeryMildVampire' class extends 'Vampire' class
'Chupacabra' class extends 'Monster' implements 'BloodSuckable'
But we can also do this:
'VeryMildVampire' extends 'Monster' implements Dangerous, Lethal, Vampiric
'Chupacabra' extends 'Monster' implements Dangerous, Vampiric
The second way here creates a 'Vampiric' interface so that we can more easily define a related monster rather than create a bunch of interfaces which define vampiric behaviors (like in the first example). But this breaks the IS-A relationship. So I'm confused...


Remember the basic concept when using abstract classes or interfaces.
Abstract classes are used when class to extended is more closely coupled to the class implementing it, i.e when both have a parent-child relation.
In example:
abstract class Dog {}
class Breed1 extends Dog {}
class Breed2 extends Dog {}
Breed1 and Breed2 are both types of a dog and has some common behavior as a dog.
Whereas, an interface is used when implementing class has a feature it can take from the class to implemented.
interface Animal {
void eat();
void noise();
}
class Tiger implements Animal {}
class Dog implements Animal {}
Tiger and Dog are two different category but both eat and make noises ,which are different. So they can use eat and noise from Animal.


Use an abstract class when you want to make one or more methods not abstract.
If you want to keep all abstract, use an interface.


This is question that will come to when designing class hierarchies that are bit complicated that normal. But generally there are few things you need to know when using abstract classes and interfaces
Abstract Class
Allows you to leverage the power of using constructors and constructor overriding
Restrict the class having multiple inheritance(This is particularly useful if you are designing a complicated API)
Instance variables and method implementations
Leverage the power of method super calling(Use super to call the parent abstract class's implementation)
Interface
Enables multiple inheritance - you can implement n number of interfaces
Allows to represent only conceptual methods (No method bodies)
Generally use Interfaces for '-able' clause(as in functionality).
Eg:-
Runnable
Observable
Use abstract classes for something like is-a(evolution format).
Eg:-
Number
Graphics
But hard and fast rules are not easy to create. Hope this helps


You have quite a few questions here. But I think basically you are asking about interface vs. abstract class.
With interfaces, you can have classes that implement multiple interfaces. However, interface is not durable if you want to use it as the API. Once the interface is published, it's hard to modify the interface because it will break other people's codes.
With abstract class, you can only extends one class. However, abstract class is durable for API because you can still modify in later versions without breaking other people's code. Also with abstract class, you can have predefined implementation. For example, in your Triangle example, for abstract class, you may have a method countEdges() which returns 3 by default.


This is a question that comes up very often, yet there is no single "right" answer that will please everyone.
Classes represent is-a relationships and interfaces represent can-do behaviour. I usually go by a few empirical rules:
Stick with a class (abstract/concrete) unless you are certain that you need an interface.
If you do use interfaces, slice them into very specific functionality. If an interface contains more than a few methods, you're doing it wrong.
Further, most examples of shapes and persons (or vampires for that matter!) are usually poor examples of real-world models. The "right" answer depends on what your application requires. For instance, you mentioned:
class Vampire extends Monster implements Dangerous, Lethal, BloodSuckable
Does your application really need all these interfaces? How many different types of Monsters are there? Do you actually have classes other than Vampire that implement BloodSuckable?
Try not to generalize too much and extract interfaces when you have no need for them. This goes back to the rule of thumb: stick with a simple class unless your use case demands an interface.


This is a good question. There are many good and bad answers for this question. Typical question is, what is the difference between an abstract class an interface? Lets see where you use abstract classes and where you use interface.
Where to use abstract classes:
In terms of OOP, If there is an inheritance hierarchy then you should use an abstract class to model your design.
Where to use interfaces:
When you have to connect different contracts(non related classes) using one common contract then you should use an interface. Lets take Collection framework as an example.
Queue,List,Set have different structures from their implementation.But still they share some common behaviors like add(),remove(). So we can create an interface called Collection and the we have declared common behaviors in the interface. As you see, ArrayList implements all the behaviors from both List and RandomAccess interfaces.Doing so we can easily add new contracts without changing the existing logic. This is called as "coding to an interface".


Your shape example is good. I look at it this way:
You only have abstract classes when you have methods or member variables that are shared. For your example for Shape you've only got a single, unimplemented method. In that case always use an interface.
Say you had an Animal class. Each Animal keeps track of how many limbs it has.
public abstract class Animal
{
private int limbs;
public Animal(int limbs)
{
this.limbs = limbs;
}
public int getLimbCount()
{
return this.limbs;
}
public abstract String makeNoise();
}
Because we need to keep track of how many limbs each animal has, it makes sense to have the member variable in the superclass. But each animal makes a different type of noise.
So we need to make it an abstract class as we have member variables and implemented methods as well as abstract methods.
For your second question, you need to ask yourself this.
Is a Triangle always going to be a shape?
If so, you need to have Triangle extend from the Shape interface.
So in conclusion - with your first set of code examples, choose the interface. With the last set, choose the second way.

Related

Why Animal is a superclass to Lion but Vehicle is a interface that Car implements? [duplicate]

I've been reading a lot about interfaces and class inheritance in Java, and I know how to do both and I think I have a good feel for both. But it seems that nobody ever really compares the two side by side and explains when and why you would want to use one or the other. I have not found a lot of times when implementing an interface would be a better system than extending a superclass.
So when do you implement an interface and when do you extend a superclass?

Use an interface if you want to define a contract. I.e. X must take Y and return Z. It doesn't care how the code is doing that. A class can implement multiple interfaces.
Use an abstract class if you want to define default behaviour in non-abstract methods so that the endusers can reuse it without rewriting it again and again. A class can extend from only one other class. An abstract class with only abstract methods can be as good definied as an interface. An abstract class without any abstract method is recognizeable as the Template Method pattern (see this answer for some real world examples).
An abstract class in turn can perfectly implement an interface whenever you want to provide the enduser freedom in defining the default behaviour.

You should choose an interface if all you want is to define a contract i.e. method signatures that you want the inheriting classes to implement. An interface can have no implementation at all. The inheriting classes are free to choose their own implementation.
Sometimes you want to define partial implementation in a base type and want to leave the rest to inheriting classes. If that is the case, choose an abstract class. An abstract class can define method implementations and variables while leaving some methods as abstract. Extending classes can choose how to implement the abstract methods while they also have the partial implementation provided by the superclass.
One extreme of abstract classes is a pure abstract class - one that has only abstract methods and nothing else. If it comes to pure abstract class vs. an interface, go with the interface. Java allows only single implementation inheritance whereas it allows multiple interface inheritance meaning that a class can implement multiple interfaces but can extend only one class. So choosing a pure abstract class over the interface will mean that the subclass will not be allowed to extend any other class while implementing the abstract methods.

Use an interface to define behavior. User (abstract) classes (and subclasses) to provide implementation. They are not mutually exclusive; they can all work together.
For example, lets say you are defining a data access object. You want your DAO to be able to load data. So put a load method on the interface. This means that anything that wants to call itself a DAO must implement load. Now lets say you need to load A and B. You can create a generic abstract class that is parameterized (generics) to provide the outline on how the load works. You then subclass that abstract class to provide the concrete implementations for A and B.

The main reason for using abstract classes and interfaces are different.
An abstract class should be used when you have classes that have identical implementations for a bunch of methods, but vary in a few.
This may be a bad example, but the most obvious use of abstract classes in the Java framework is within the java.io classes. OutputStream is just a stream of bytes. Where that stream goes to depends entirely on which subclass of OutputStream you're using... FileOutputStream, PipedOutputStream, the output stream created from a java.net.Socket's getOutputStream method...
Note: java.io also uses the Decorator pattern to wrap streams in other streams/readers/writers.
An interface should be used when you just want to guarantee that a class implements a set of methods, but you don't care how.
The most obvious use of interfaces is within the Collections framework.
I don't care how a List adds/removes elements, so long as I can call add(something) and get(0) to put and get elements. It may use an array (ArrayList, CopyOnWriteArrayList), linked list (LinkedList), etc...
The other advantage in using interfaces is that a class may implement more than one. LinkedList is an implementation of both List and Deque.

No one?
http://mindprod.com/jgloss/interfacevsabstract.html
EDIT: I should supply more than a link
Here's a situation. To build on the car example below, consider this
interface Drivable {
void drive(float miles);
}
abstract class Car implements Drivable {
float gallonsOfGas;
float odometer;
final float mpg;
protected Car(float mpg) { gallonsOfGas = 0; odometer = 0; this.mpg = mpg; }
public void addGas(float gallons) { gallonsOfGas += gallons; }
public void drive(float miles) {
if(miles/mpg > gallonsOfGas) throw new NotEnoughGasException();
gallonsOfGas -= miles/mpg;
odometer += miles;
}
}
class LeakyCar extends Car { // still implements Drivable because of Car
public addGas(float gallons) { super.addGas(gallons * .8); } // leaky tank
}
class ElectricCar extends Car {
float electricMiles;
public void drive(float miles) { // can we drive the whole way electric?
if(electricMiles > miles) {
electricMiles -= miles;
odometer += miles;
return; // early return here
}
if(electricMiles > 0) { // exhaust electric miles first
if((miles-electricMiles)/mpg > gallonsOfGas)
throw new NotEnoughGasException();
miles -= electricMiles;
odometer += electricMiles;
electricMiles = 0;
}
// finish driving
super.drive(miles);
}
}

I think that interfaces work best when you use them to express that the object has a certain property or behavior, that spans multiple inheritance trees, and is only clearly defined for each class.
For example think of Comparable. If you wanted to create a class Comparable to be extended by other classes, it would have to be very high on the inheritance tree, possible right after Object, and the property it expresses is that two objects of that type can be compared, but there's no way to define that generally (you can't have an implementation of compareTo directly in the Comparable class, it's different for every class that implements it).
Classes work best when they define something clear, you know what properties and behaviors they have, and have actual implementations for methods, that you want to pass down to the children.
So classes work when you need to define a concrete object like a human, or a car, and interfaces work better when you need more abstract behavior that's too general to belong to any inheritance tree, like the ability to be compared (Comparable) or to be run (Runnable).

One method of choosing between an interface and a base class is the consideration of code ownership. If you control all the code then a base class is a viable option. If on the other hand many different companies might want to produce replaceable components, that is define a contract then an interface is your only choice.

I found some articles, particularly some who describe why you should not use implementation inheritance (i.e. superclasses):
Why extends is evil
Inheritance of implementation is evil
Implementation inheritance
Implementation inheritance
Java inheritance FAQ

I guess I'll give the classic car example.
When you have a car interface, you can create a Ford, a Chevy, and an Oldsmobile. In other words, you create different kinds of cars from a car interface.
When you have a car class, you can then extend the car class to make a truck, or a bus. In other words, you add new attributes to the sub classes while keeping the attributes of the base or super class.

You can think of extending from a super class if the derived class is of the same type.I mean that when a class extends an abstract class, they both should be of the same type, the only difference being that the super class has a more general behavior and the sub class has a more specific behavior. An interface is a totally different concept. When a class implements an interface, its either to expose some API(contract) or to get certain behavior. To give an example, I would say that Car is an abstract class. You can extend many classes from it like say Ford, Chevy and so on which are each of type car. But then if you need certain specific behavior like say you need a GPS in a car then the concrete class, eg Ford should implement GPS interface.

If you only want to inherit method signatures (name, arguments, return type) in the subclasses, use an interface, but if you also want to inherit implementation code, use a superclass.

Can I use interfaces for inheritance of properties in java 8?

I have 4 classes : "stones", "seaweed", "sprats" and "pikes", each successive class inherits the properties of the previous one.
Class "stones" have the coordinates, a class "seaweed" added to the coordinates the lifetime and the rate of growth, as well as the birth of a new seaweed (division of old), in "sprats" added method of eating seaweed.
Should I use normal java classes to express such inheritance or is there another way for such inheritance?

In such a case when semantically there is no real relation between the two objects I would discourage directly using class inheritance.
If you wish to express the fact that these classes have certain aspects of their behaviour in common, you might want to use interfaces which express these sets of properties. This works because a class can implement multiple interfaces, so you can pick and choose which to implement in each class. This also introduces greater flexibility since a linear ordering of the different, not strictly related functionalities is not necessary.
Example: You could have
public interface WorldObject {...}
public interface Organism extends WorldObject {...}
public interface Plant extends Organism {...}
public interface Animal extends Organism {...}
public interface Eater<T> {...}
public class Stone implements WorldObject {...}
public class Seaweed implements Plant {...}
public class Sprat implements Animal, Eater<Seaweed> {...}
etc.

Composition is good alternative to inheritance.
So you will have additional classes such as Coordinates, LifeStyle, Consumer
and define your classes
class Stone{
Coordinates coordinates;
}
class Seaweed{
Coordinates coordinates;
LifeStyle lifestyle;
}
class Sprats{
Coordinates coordinates;
LifeStyle lifestyle;
List<Consumer<?>> consumers;
}
is it better alternative than inheritance, it depends on your project.

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 is using abstract class better for inheritance than using normal class? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Consider this sample code where I have used normal class to implement generalized concept first and then using subclasses to specialize:
package check;
class figure{
void area(){
System.out.println("\n Superclass for any figure"); //An useless print statement
}
}
class triangle extends figure{
void area()
{
System.out.println("\n Code to determine area of a triangle");
}
}
For the same implementation using abstract class, the code would be:
abstract class figure1{
abstract void area();
}
class triangle1 extends figure1{
void area()
{
System.out.println("\n Code to determine area of a triangle");
}
}
Now reading my textbook in JAVA (Herbert Schildt, Complete Reference, 7th edition) it appeared to me that the writer wants to convey that somehow using abstract class is better in case of generalization-specialization approaches. However, I failed to understand how it is better than using normal class. Using abstract class essentially enforces us to extend the base class and that's all; other than that I am unable to see any huge difference in the implementation. So can anybody make me understand how using abstract class is a better practice/approach than using normal class?

An abstract class can never be instantiated and this is the real advantage of the abstract class.
For example, the class Animal could be an abstract class; but in real life you can never have an instance of an Animal; that makes no sense at all as you can't just create an Animal, you create an Animal, such as a Cat or Dog in real life as they are real-world entities. So in terms of the translation between the code design and the real-world concept or situation, abstract classes are much better as they can provide a much neater portrayal of the real-world situation.

There is no "better" nor "worse", it depends on your purpose.
An abstract class allows declaring abstract methods that need to be implemented by the child class if the child class is not abstract itself.
A non-abstract does not, you need to implement all your declared methods.
Think of an abstract class as a "generic" object, that wouldn't exist as such in real life but provides a good generalization for a number of other concrete objects.
Think of the non-abstract class as something you could actually point your finger at in real life.

Using an abstract method means that nobody can instantiate the class.
In other words, noone can create a Shape and then use that: they have to create something that extends shape, such as a Circle or a Rectangle.

One more advantage to having abstract classes in addition to what others pointed out is you can add more sub-classes to it as need arise. Suppose you have Shape abstract class and Circle and Triangle concrete classes, in future if you've a need for Polygon you can easily add that.
Take abstract class as a high level entity and concrete class as a more specialized form of a generic entity with specialized class inheriting all the properties of generic class and defining its own behavior where it differs from generic class

You might also look at Effective Java's directive about the equals() method. It is tricky, if not downright impossible, to implement that method in a contract-respecting way when you have two concrete classes in an inheritance relationship.

An abstract class is a class that is declared abstract—it may or may not include abstract methods. Abstract classes cannot be instantiated, but they can be subclassed. Abstract classes are most commonly subclassed to share pieces of implementation. A single abstract class is subclassed by similar classes that have a lot in common, which provides flexibility in OOP design. And we use this class for abstracting out the properties which are common among various type of Classes.
For example, Suppose we circles, rectangles, lines graphics object which has lots in common about their states, for example: position, orientation, line color, fill color. However, If we define an Abstract class as:
abstract class GraphicObject {
int x, y;
Color color;
abstract void draw();
}
Now, Each non-abstract subclass of GraphicObject, such as Circle and Rectangle, must provide implementations for the draw method, which may contain drawing code for specific location with specific color( i may want a circle to be drawn with color red, and a rectangle with color green with different location (x,y)):
class Circle extends GraphicObject {
void draw() {
...
}
}
class Rectangle extends GraphicObject {
void draw() {
...
}
}
One of the most powerful object-oriented techniques is subtype polymorphism, the ability to handle multiple specialized types from a single, supertype viewpoint.
Check out this article to understand in depth:
Reveal the magic behind subtype polymorphism
Maximize flexibility with interfaces and abstract classes

Using abstract class essentially enforces us to extend the base class and that's all; other than that I am unsable to see any huge difference in the implementation. So can anybody make me understand how using abstract class is a better practice/approach than using normal class?
An abstract class serves the same purpose as an Interface -- it creates a functional contract that says if I have an instance of it, I know these methods will be available. The additional benefit of an abstract class is that it can contain implementations of methods that subclasses will share without the need to implement said method in the subclasses.
public abstract class AbstractFoo{
public abstract void process(); // subclasses forced to implement
public String getValue(Object b){
String s = "Hi!!";
// stuff happens....maybe
return s;
}
public class ConcreteFoo extends AbstractFoo{
public void process(){
// you forced me to!! Oh well, I want to honor the contract
// anyway
}
}
public class Main{
public static void main(String[] args){
AbstractFoo f = new ConcreteFoo();
System.out.println(f.getValue(new Object()));
}
}
This gives
Hi!!
as the output. Notice ConcreteFoo didn't have to implement getValue.

Difference between Inheritance and Composition

Are Composition and Inheritance the same?
If I want to implement the composition pattern, how can I do that in Java?

They are absolutely different. Inheritance is an "is-a" relationship. Composition is a "has-a".
You do composition by having an instance of another class C as a field of your class, instead of extending C. A good example where composition would've been a lot better than inheritance is java.util.Stack, which currently extends java.util.Vector. This is now considered a blunder. A stack "is-NOT-a" vector; you should not be allowed to insert and remove elements arbitrarily. It should've been composition instead.
Unfortunately it's too late to rectify this design mistake, since changing the inheritance hierarchy now would break compatibility with existing code. Had Stack used composition instead of inheritance, it can always be modified to use another data structure without violating the API.
I highly recommend Josh Bloch's book Effective Java 2nd Edition
Item 16: Favor composition over inheritance
Item 17: Design and document for inheritance or else prohibit it
Good object-oriented design is not about liberally extending existing classes. Your first instinct should be to compose instead.
See also:
Composition versus Inheritance: A Comparative Look at Two Fundamental Ways to Relate Classes

Composition means HAS A
Inheritance means IS A
Example: Car has a Engine and Car is a Automobile
In programming this is represented as:
class Engine {} // The Engine class.
class Automobile {} // Automobile class which is parent to Car class.
class Car extends Automobile { // Car is an Automobile, so Car class extends Automobile class.
private Engine engine; // Car has an Engine so, Car class has an instance of Engine class as its member.
}

How inheritance can be dangerous ?
Lets take an example
public class X{
public void do(){
}
}
Public Class Y extends X{
public void work(){
do();
}
}
1) As clear in above code , Class Y has very strong coupling with class X. If anything changes in superclass X , Y may break dramatically. Suppose In future class X implements a method work with below signature
public int work(){
}
Change is done in class X but it will make class Y uncompilable. SO this kind of dependency can go up to any level and it can be very dangerous. Every time superclass might not have full visibility to code inside all its subclasses and subclass may be keep noticing what is happening in superclass all the time. So we need to avoid this strong and unnecessary coupling.
How does composition solves this issue?
Lets see by revising the same example
public class X{
public void do(){
}
}
Public Class Y{
X x = new X();
public void work(){
x.do();
}
}
Here we are creating reference of X class in Y class and invoking method of X class by creating an instance of X class.
Now all that strong coupling is gone. Superclass and subclass are highly independent of each other now. Classes can freely make changes which were dangerous in inheritance situation.
2) Second very good advantage of composition in that It provides method calling flexibility, for example :
class X implements R
{}
class Y implements R
{}
public class Test{
R r;
}
In Test class using r reference I can invoke methods of X class as well as Y class. This flexibility was never there in inheritance
3) Another great advantage : Unit testing
public class X {
public void do(){
}
}
Public Class Y {
X x = new X();
public void work(){
x.do();
}
}
In above example, if state of x instance is not known, it can easily be mocked up by using some test data and all methods can be easily tested. This was not possible at all in inheritance as you were heavily dependent on superclass to get the state of instance and execute any method.
4) Another good reason why we should avoid inheritance is that Java does not support multiple inheritance.
Lets take an example to understand this :
Public class Transaction {
Banking b;
public static void main(String a[])
{
b = new Deposit();
if(b.deposit()){
b = new Credit();
c.credit();
}
}
}
Good to know :
composition is easily achieved at runtime while inheritance provides its features at compile time
composition is also know as HAS-A relation and inheritance is also known as IS-A relation
So make it a habit of always preferring composition over inheritance for various above reasons.

The answer given by #Michael Rodrigues is not correct (I apologize; I'm not able to comment directly), and could lead to some confusion.
Interface implementation is a form of inheritance... when you implement an interface, you're not only inheriting all the constants, you are committing your object to be of the type specified by the interface; it's still an "is-a" relationship. If a car implements Fillable, the car "is-a" Fillable, and can be used in your code wherever you would use a Fillable.
Composition is fundamentally different from inheritance. When you use composition, you are (as the other answers note) making a "has-a" relationship between two objects, as opposed to the "is-a" relationship that you make when you use inheritance.
So, from the car examples in the other questions, if I wanted to say that a car "has-a" gas tank, I would use composition, as follows:
public class Car {
private GasTank myCarsGasTank;
}
Hopefully that clears up any misunderstanding.

Inheritance brings out IS-A relation. Composition brings out HAS-A relation.
Strategy pattern explain that Composition should be used in cases where there are families of algorithms defining a particular behaviour.Classic example being of a duck class which implements a flying behaviour.
public interface Flyable{
public void fly();
}
public class Duck {
Flyable fly;
public Duck(){
fly = new BackwardFlying();
}
}
Thus we can have multiple classes which implement flying
eg:
public class BackwardFlying implements Flyable{
public void fly(){
Systemout.println("Flies backward ");
}
}
public class FastFlying implements Flyable{
public void fly(){
Systemout.println("Flies 100 miles/sec");
}
}
Had it been for inheritance, we would have two different classes of birds which implement the fly function over and over again. So inheritance and composition are completely different.

Composition is just as it sounds - you create an object by plugging in parts.
EDIT the rest of this answer is erroneously based on the following premise.
This is accomplished with Interfaces.
For example, using the Car example above,
Car implements iDrivable, iUsesFuel, iProtectsOccupants
Motorbike implements iDrivable, iUsesFuel, iShortcutThroughTraffic
House implements iProtectsOccupants
Generator implements iUsesFuel
So with a few standard theoretical components you can build up your object. It's then your job to fill in how a House protects its occupants, and how a Car protects its occupants.
Inheritance is like the other way around. You start off with a complete (or semi-complete) object and you replace or Override the various bits you want to change.
For example, MotorVehicle may come with a Fuelable method and Drive method. You may leave the Fuel method as it is because it's the same to fill up a motorbike and a car, but you may override the Drive method because the Motorbike drives very differently to a Car.
With inheritance, some classes are completely implemented already, and others have methods that you are forced to override. With Composition nothing's given to you. (but you can Implement the interfaces by calling methods in other classes if you happen to have something laying around).
Composition is seen as more flexible, because if you have a method such as iUsesFuel, you can have a method somewhere else (another class, another project) that just worries about dealing with objects that can be fueled, regardless of whether it's a car, boat, stove, barbecue, etc. Interfaces mandate that classes that say they implement that interface actually have the methods that that interface is all about. For example,
iFuelable Interface:
void AddSomeFuel()
void UseSomeFuel()
int percentageFull()
then you can have a method somewhere else
private void FillHerUp(iFuelable : objectToFill) {
Do while (objectToFill.percentageFull() <= 100) {
objectToFill.AddSomeFuel();
}
Strange example, but it's shows that this method doesn't care what it's filling up, because the object implements iUsesFuel, it can be filled. End of story.
If you used Inheritance instead, you would need different FillHerUp methods to deal with MotorVehicles and Barbecues, unless you had some rather weird "ObjectThatUsesFuel" base object from which to inherit.

Are Composition and Inheritance the same?
They are not same.
Composition : It enables a group of objects have to be treated in the same way as a single instance of an object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies
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.
If I want to implement the composition pattern, how can I do that in Java?
Wikipedia article is good enough to implement composite pattern in java.
Key Participants:
Component:
Is the abstraction for all components, including composite ones
Declares the interface for objects in the composition
Leaf:
Represents leaf objects in the composition
Implements all Component methods
Composite:
Represents a composite Component (component having children)
Implements methods to manipulate children
Implements all Component methods, generally by delegating them to its children
Code example to understand Composite pattern:
import java.util.List;
import java.util.ArrayList;
interface Part{
public double getPrice();
public String getName();
}
class Engine implements Part{
String name;
double price;
public Engine(String name,double price){
this.name = name;
this.price = price;
}
public double getPrice(){
return price;
}
public String getName(){
return name;
}
}
class Trunk implements Part{
String name;
double price;
public Trunk(String name,double price){
this.name = name;
this.price = price;
}
public double getPrice(){
return price;
}
public String getName(){
return name;
}
}
class Body implements Part{
String name;
double price;
public Body(String name,double price){
this.name = name;
this.price = price;
}
public double getPrice(){
return price;
}
public String getName(){
return name;
}
}
class Car implements Part{
List<Part> parts;
String name;
public Car(String name){
this.name = name;
parts = new ArrayList<Part>();
}
public void addPart(Part part){
parts.add(part);
}
public String getName(){
return name;
}
public String getPartNames(){
StringBuilder sb = new StringBuilder();
for ( Part part: parts){
sb.append(part.getName()).append(" ");
}
return sb.toString();
}
public double getPrice(){
double price = 0;
for ( Part part: parts){
price += part.getPrice();
}
return price;
}
}
public class CompositeDemo{
public static void main(String args[]){
Part engine = new Engine("DiselEngine",15000);
Part trunk = new Trunk("Trunk",10000);
Part body = new Body("Body",12000);
Car car = new Car("Innova");
car.addPart(engine);
car.addPart(trunk);
car.addPart(body);
double price = car.getPrice();
System.out.println("Car name:"+car.getName());
System.out.println("Car parts:"+car.getPartNames());
System.out.println("Car price:"+car.getPrice());
}
}
output:
Car name:Innova
Car parts:DiselEngine Trunk Body
Car price:37000.0
Explanation:
Part is a leaf
Car contains many Parts
Different Parts of the car have been added to Car
The price of Car = sum of ( Price of each Part )
Refer to below question for Pros and Cons of Composition and Inheritance.
Prefer composition over inheritance?

as another example, consider a car class, this would be a good use of composition, a car would "have" an engine, a transmission, tires, seats, etc. It would not extend any of those classes.

Composition is where something is made up of distinct parts and it has a strong relationship with those parts. If the main part dies so do the others, they cannot have a life of their own. A rough example is the human body. Take out the heart and all the other parts die away.
Inheritance is where you just take something that already exists and use it. There is no strong relationship. A person could inherit his fathers estate but he can do without it.
I don't know Java so I cannot provide an example but I can provide an explanation of the concepts.

In Simple Word Aggregation means Has A Relationship ..
Composition is a special case of aggregation. In a more specific manner, a restricted aggregation is called composition. When an object contains the other object, if the contained object cannot exist without the existence of container object, then it is called composition.
Example: A class contains students. A student cannot exist without a class. There exists composition between class and students.
Why Use Aggregation
Code Reusability
When Use Aggregation
Code reuse is also best achieved by aggregation when there is no is a Relation ship
Inheritance
Inheritance is a Parent Child Relationship Inheritance Means Is A RelationShip
Inheritance in java is a mechanism in which one object acquires all the properties and behaviors of parent object.
Using inheritance in Java
1 Code Reusability.
2 Add Extra Feature in Child Class as well as Method Overriding (so runtime polymorphism can be achieved).

Inheritance between two classes, where one class extends another class establishes "IS A" relationship.
Composition on the other end contains an instance of another class in your class establishes "Has A" relationship. Composition in java is is useful since it technically facilitates multiple inheritance.

Though both Inheritance and Composition provides code reusablility, main difference between Composition and Inheritance in Java is that Composition allows reuse of code without extending it but for Inheritance you must extend the class for any reuse of code or functionality. Another difference which comes from this fact is that by using Composition you can reuse code for even final class which is not extensible but Inheritance cannot reuse code in such cases. Also by using Composition you can reuse code from many classes as they are declared as just a member variable, but with Inheritance you can reuse code form just one class because in Java you can only extend one class, because multiple Inheritance is not supported in Java. You can do this in C++ though because there one class can extend more than one class. BTW, You should always prefer Composition over Inheritance in Java, its not just me but even Joshua Bloch has suggested in his book

I think this example explains clearly the differences between inheritance and composition.
In this exmple, the problem is solved using inheritance and composition. The author pays attention to the fact that ; in inheritance, a change in superclass might cause problems in derived class, that inherit it.
There you can also see the difference in representation when you use a UML for inheritance or composition.
http://www.javaworld.com/article/2076814/core-java/inheritance-versus-composition--which-one-should-you-choose-.html

Inheritances Vs Composition.
Inheritances and composition both are used to re-usability and extension of class behavior.
Inheritances mainly use in a family algorithm programming model such as IS-A relation type means similar kind of object. Example.
Duster is a Car
Safari is a Car
These are belongs to Car family.
Composition represents HAS-A relationship Type.It shows the ability of an object such as Duster has Five Gears , Safari has four Gears etc. Whenever we need to extend the ability of an existing class then use composition.Example we need to add one more gear in Duster object then we have to create one more gear object and compose it to the duster object.
We should not make the changes in base class until/unless all the derived classes needed those functionality.For this scenario we should use Composition.Such as
class A Derived by Class B
Class A Derived by Class C
Class A Derived by Class D.
When we add any functionality in class A then it is available to all sub classes even when Class C and D don't required those functionality.For this scenario we need to create a separate class for those functionality and compose it to the required class(here is class B).
Below is the example:
// This is a base class
public abstract class Car
{
//Define prototype
public abstract void color();
public void Gear() {
Console.WriteLine("Car has a four Gear");
}
}
// Here is the use of inheritence
// This Desire class have four gears.
// But we need to add one more gear that is Neutral gear.
public class Desire : Car
{
Neutral obj = null;
public Desire()
{
// Here we are incorporating neutral gear(It is the use of composition).
// Now this class would have five gear.
obj = new Neutral();
obj.NeutralGear();
}
public override void color()
{
Console.WriteLine("This is a white color car");
}
}
// This Safari class have four gears and it is not required the neutral
// gear and hence we don't need to compose here.
public class Safari :Car{
public Safari()
{ }
public override void color()
{
Console.WriteLine("This is a red color car");
}
}
// This class represents the neutral gear and it would be used as a composition.
public class Neutral {
public void NeutralGear() {
Console.WriteLine("This is a Neutral Gear");
}
}

Composition means creating an object to a class which has relation with that particular class.
Suppose Student has relation with Accounts;
An Inheritance is, this is the previous class with the extended feature. That means this new class is the Old class with some extended feature.
Suppose Student is Student but All Students are Human. So there is a relationship with student and human. This is Inheritance.

Inheritence means reusing the complete functionality of a class, Here my class have to use all the methods of the super class and my class will be titely coupled with the super class and code will be duplicated in both the classes in case of inheritence.
But we can overcome from all these problem when we use composition to talk with another class . composition is declaring an attribute of another class into my class to which we want to talk. and what functionality we want from that class we can get by using that attribute.

No , Both are different . Composition follow "HAS-A" relationship and inheritance follow "IS-A" relationship . Best Example for composition was Strategic pattern .

Categories

Resources