why do we really need interface and abstract classes in java?

[antsi klando]

This is a very confusing concept. What I always think is that, why don't I define my methods in a class, rather than going a level up and declaring it first in an abstract class/interface?
If the point is to have different implementations for different needs, then we have the option to override the methods.Please explain with simple examples.

[Janeice DelVecchio]

An interface is a promise. You know if something implements an interface it will do what it says on the box. You have the methods that are offered by the interface.

So when you say you want a List, whether it's an ArrayList or a LinkedList, you know what you can and can't do. ArrayLists do List things differently than LinkedList, but you don't care. You know you can add, iterate, remove, etc stuff from the List.

An abstract class is a different kind of promise. The abstract class says "ok if you're going to extend me, you need to fulfill this contract/promise, because I NEED that to work. I have promised myself and others that we have that behavior." For example, an abstract class of Vehicle might know it needs to have a method, getCountOfWheels(), but it would return something different for a motorcycle than a car. The developer creating the abstract class might know there's bunches of Vehicles, but he might not know everything about all of them.... or sometimes it might be imperative that everyone implements their own way.

[Rico Felix]

An abstract class does exactly what is says it does which is to be abstract... Its like generalizing a concept that can be elaborated on to provide specific implementations based on that abstract idea....

Lets take the concept of a ball... When you hear the world ball its abstract enough for you not to think about something specific such as a soccer ball or a baseball... You just know that a ball has certain characteristics and behaviour that makes it a ball such as being spherical and the ability to bounce... now you can use this idea to create specifics such as a soccer ball or baseball having these characteristics and behaviour in their own special way...

[Ben Ooms]

Abstract classes and interfaces are needed to produce maintainable code. If I take your example of the ball and subclasses like soccer ball.

In this example of course you could make a regular Ball class and a sub class called SoccerBall. But what if someone decided to create a Ball instance? This wasn't your intention because your design was expecting specific implementation of a Ball being spherical and having some ability.

So a abstract class Ball would be a good choice to start with so that you enforce that specific implementation are made and generalision is achieved so that you can create methods for processing Ball instances regardless of the Specific implementations.
This can be refined even more because now you have the possibility to define soccer balls and baseballs and so on. But not all ball do bounce (take a bowling ball as example). With only the Abstract class Ball you could create a Bowling ball subclass with a bounce ability of none, fase or 0.
If whe also define a Bounceable interface whe could create methods for Bounceable instances instead of Ball instance with the benefit of knowing beforehand that Bounceable object always bounce.

abstract class Ball{ protected boolean spherical;// getters and setters obmitted}
interface Bounceable { void doBounce();}

class Baseball extends Ball implements Bounceable {} // Without knowing the innerparts or state of this class whe already known it can bounce

class Bowlingball extends Ball {} // Without knowing the innerparts  or state of this class whe already know it cannot bounce

[Ulf Dittmer]

class Baseball ... implements Bounceable

Not much, though

[Ben Ooms]

Ulf Dittmer wrote:

class Baseball ... implements Bounceable

Not much, though

Indeed,

[Campbell Ritchie]

’Ware tangent! Don't want to have to bounce this thread to MD

[antsi klando]

But I still do not understand why do we have to go for an abstract class or an interface, because we can simply override the methods here. As for the Ball example, we can go for the below code..

class Ball {
	void doBounce() {
		System.out.println("The Ball can bounce");
	}
}

class Baseball extends Ball {
	void doBounce() {
		System.out.println("The Baseball can bounce");
	}

	class Bowlingball extends Ball {
		void doBounce() {
			System.out.println("The Bowlingball cannot bounce");
		}
	}

[Janeice DelVecchio]

Ball takes care of generic Ball things, each extender takes care of the abstract behavior to fulfill the contract. You know if you're a ball, you need to have a bounce factor, so bounce() will work.

public abstract class Ball{

    public void bounce(){
         int height = getBounceFactor() * 20;
         System.out.println("bouncing at " + height + " feet");
    }

    public abstract int getBounceFactor();
}


public class Baseball extends Ball{

    public int getBounceFactor(){
         return 1;
    }
}


public class Basketball extends Ball{

    public int getBounceFactor(){
         return 100;
    }
}

[Tess Jacobs]

The purpose of an interface is to share abstract behaviour (unimplemented behaviour) among several classes in your program, for example, you may want several classes in your program to be Lists.

The purpose of an abstract class is to share abstract behaviour, but in addition, you may also want to share concrete behaviour (implemented behaviour) among several classes in your program, for example, you may want several classes in your program to be AbstractLists; in other words,

you may want to provide several classes in your program with default constructors to perform default construction. Subclass constructors may then complete the construction.

you may want to provide several classes in your program with default methods. Subclass methods may then override some or all of them.

When writing a bunch of classes, it’s a good idea to ask yourself if you can tie some classes together with an interface or an abstract class because the more abstraction levels you can apply to your code, the easier it is to comprehend, maintain and evolve. Abstraction is a powerful tool used to understand and solve complex problems.

[E Armitage]

But I still do not understand why do we have to go for an abstract class or an interface, because we can simply override the methods here. As for the Ball example, we can go for the below code..

Sometimes you want to separate packaging between your interfaces and implementation classes to enable some projects to only depend on the interfaces and not on any implementation logic, e.g in remote EJB invocation.
This separation also scales development because teams can now work against the interface at the same time without impacting each other's code bases.e.g if you don't have interfaces, when they guy writing the implementation class adds a new dependency required for his implementation then everyone using that class also needs to update their project with the dependencies.

[antsi klando]

But, we can override the method as in the code below right?

public class Ball{  
	  
    public void bounce(){  
         int height = getBounceFactor() * 20;  
         System.out.println("bouncing at " + height + " feet");  
    }  
  
    public int getBounceFactor(){
    	return 0;
    }
}  
  
  
public class Baseball extends Ball{  
  
    public int getBounceFactor(){  
         return 1;  
    }  
}  
  
  
public class Basketball extends Ball{  
  
    public int getBounceFactor(){  
         return 100;  
    }  
}  

[Janeice DelVecchio]

Yes. But now there's no guarantee that the children will override it.

With an abstract class there is. Think of a world where there are many developers. Developer A says "all balls are the same, except they bounce differently. I will take care of everything that's the same and other developers can just spend their time working on bouncing." Now the developers working on Baseball, Basketball, Superball have a much easier task. The guy working on AmericanFootball will need to override the concrete method isRound in superclass Ball and also implement the abstract method.

With an interface, you can treat seemingly unrelated objects similarly. Say Kangaroo and Basketball both implement Bounceable. Now you can pop them in a collection together and call any method in the Bounceable interface on both.

[Rico Felix]

To try and clear up the confusion once and for all I would rely on my favourite concept of shapes...

If I say shape you'll know what I mean... I didn't say if I was thinking about a circle or a rectangle or a square... you might have an image in mind but I wouldn't have to get that specific because you understand the idea of a shape which is the abstraction of a shape... you have seen enough shapes to abstract the idea of what shape means... Abstraction mean you focus on the essential quality of something rather than focus on a specific thing which is to discard of the things that are irrelevant or unimportant...

Now having this information to rely on... you cannot just create a shape object because its just an idea, an abstraction of what a shape is suppose to be like... its incomplete... What we can say about a shape is that its suppose to have an area

public abstract class Shape {
    public abstract double getArea();
}

In Java we use the keyword abstract while declaring a class to say that this class is incomplete and you cannot create an instance of it... you can also see that the method has no body also assuring the incompleteness...

If we try to create an instance of Shape we would get a compile time error to say this is an incomplete class and we cannot create a direct object of this type:

Shape shape = new Shape(); // compile time error

Instead we use this abstraction and implement something specific like a circle:

public class Circle extends Shape {
    private double radius;
    public Circle(double r) {
        radius = r;
    }
    public double getArea() {
        return Math.PI * radius * radius;
    }
}

Now we can create an instance of a specific shape which is a circle

Shape shape = new Circle(12);
System.out.printf("The area of the circle is: %.2f", shape.getArea());

There is a lot more insight on why abstract classes are beneficial but this should give you something to think about...

[Rico Felix]

An interface state the behaviour of an entity and the way in which you interact with this entity to request the behaviour...

Lets say that you want a Circle object to roll but while building the application you consider other objects can roll as well... here is where you make use of an interface

interface Rollable {
    void roll(int distance);
}

As with the abstract class you cannot create a direct object of Rollable because all it does is state behaviour... The following will generate a compile time error:

Rollable roller = new Rollable(); // compile-time error

Instead we implement the behaviour using an entity as follows:

public class Circle extends Shape implements Rollable {
    private double radius;
    public Circle(double r) {
        radius = r;
    }
    public double getArea() {
        return Math.PI * radius * radius;
    }
    public void roll(int distance) {
       System.out.println("Rolled a distance of " + distance + "cm");
    }
}

Now we can use the behaviour using an entity, in this case a circle:

Rollable roller = new Circle(12);
roller.roll(12);

There is a lot more insight on why interfaces are beneficial but this should give you something to think about...