Why use abstract class and not interface?

Question

For example a real estate builder is constructing an apartment with many flats. All the rooms in the flats have the same design, except the bedroom. The bedroom design is left for the people who would own the flats i.e; the bed Rooms can be of different designs for different flats.

I can achieve this through an abstract class like below:

public abstract class Flat
{
    //some properties

    public void livingRoom(){
       //some code
    }

    public void kitchen(){
       //some code
    }

    public abstract void bedRoom();

    }
}

An implementation class would be as follows:

public class Flat101 extends Flat
{
    public void bedRoom() {
        System.out.println("This flat has a customized bedroom");
   }        

}

Alternatively I can use an interface instead of an abstract class to achieve the same purpose like follows:

class Flat
{
  public void livingRoom(){ 
       System.out.println("This flat has a living room");
  }

  public void kitchen(){
     System.out.println("This flat has a kitchen");
  } 
}

interface BedRoomInterface
{
  public abstract void bedRoom();
}

public class Flat101 extends Flat implements BedRoomInterface
{
   public void bedRoom() {
    System.out.println("This flat has a customized bedroom");
   }
}

Now the question is : For this why should choose to use an interface (or) why should I choose to use an abstract class?

Answer 1

I feel when we need to implement some common functionality and some abstract functionality for multiple class then we should use abstract class. If we see the example of Flat, where we have some common design and some custom design, in such use case it is better to use abstract rather then use interface again to implement custom function and use of abstract as derived class doesn't create an extra instance as normal derived class.

Answer 2

I feel it is generalization means; an abstract class is most useful if the property and the behaviors of the class are common among a given package or module. One good example is drum brake; as all drum brake works same way holding brakes inside wheel drum so this behavior can be inherited in all class of cars which uses drum brake.

For interface; it is more like specification or contract which force you to implement its speciation. Let’s take an example of model of a building it has all speciation like doors, window, lift ….. But while you implement the model into actual building you we need to keep the window but the internal behavior is decided by (as the widow could be a simple widow or a slider window, the color and material …)

Hope this helps!!

Answer 3

It depends on your intention or use case. But in general, you should prefer interface over abstract classes (Item 18 in Bloch's Effective Java). Abstract classes are more fragile, because someone may modify the abstract class changing the behavior of other classes extending from it (this is a general statement).

It's more flexible to work with interfaces, because if you have BedroomInterface and LivingRoomInterface, then you can have FlatInterface implementing both interfaces, then Flat101 implementation class implements FlatInterface (instead of extending from Flat then implementing an interface). This seems clearer, and later on you can have ExecutiveFlatInterface which not only have bedroom and living room but also guess room, then Flat102 can implement from it.

Option 2 is to have Flat101 extend from Flat, then Flat implements BedroomInterface and LivingRoomInterface. This really depends on what you want to do and what methods are likely needed.

Answer 4

If you're designing an API that is going to be widely used, you'd use both: an interface to express the contract to be fulfilled by implementing classes, and an abstract class which partially implements that interface and thus permits code re-use.

As an example, consider Java's List: methods in the Collections framework (eg Collections.sort()) are written in terms of the List interface, which is partially implemented by the abstract class AbstractList, which in turn is extended into the concrete implementations LinkedList and ArrayList. LinkedList and ArrayList re-use code from AbstractList, but that does not prevent someone from writing their own completely separate implementation of List and then sorting it using Collections.sort().

That said, in a lot of circumstances this approach can be overkill. If the type hierarchy you're building is only used within a relatively small scope, its generally fine to just use abstract classes. If you decide later on that you want an interface later, its a pretty painless refactoring task to change things.

Abstract classes do have a few advantages:

• they allow you to specify abstract methods with package/protected modifiers
• they facilitate code re-use
• via the use of abstract methods and final methods on the super class they allow you to restrict the manner in which your class is subclassed, which can be useful in a wide variety of circumstances (see also: the Template pattern)
• code that references classes is generally easier to follow in an IDE (clicking "open declaration" on an abstract class type parameter is usually more useful than on an interface type parameter)

Answer 5

You can not extends more than one class but you can implements more than one interface

If you need to change frequently of your design then abstract class is better because any change happen in abstract class , no force implementation need in sub class. But If any change in interface you have to implement of the implementation class.

Answer 6

If you have a class which provides some of the functionality required by derived classes, but each derived class additionally requires differing implementation of other functionality, then an abstract class provides a means of defining the common implementation, while leaving the specific behaviors required by derived classes to be made specific to each derived class.