Interfaces and Abstract classes confusion in Java with examples

Question

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 inter

Answer 1

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.

Answer 2

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".

Answer 3

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.

Answer 4

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:-

1. Runnable
2. Observable

Use abstract classes for something like is-a(evolution format). Eg:-

1. Number
2. Graphics

But hard and fast rules are not easy to create. Hope this helps

Answer 5

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.

Answer 6

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.