Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Abstract class and interface together?

I have a section of my code where some classes are implementing an interface.

It feels correct, but there is a little duplication among the child classes - namely 3 methods.

So this is screaming out to use an abstract class.

My question is, will there be any cons in using both abstract class and interface in the following situations:

  1. Abstract class to implement the interface and child classes to extend the abstract class
  2. Child classes to extend the abstract class and implement the interface

Or

Should abstract classes and interfaces not be used together at all like this?

like image 781
Marty Wallace Avatar asked May 20 '13 11:05

Marty Wallace


People also ask

Can we use interface and abstract class together?

The instance of an abstract class can't be created. Now as all methods in an interface are abstract methods therefore we can implement it using Abstract Class.

Can abstract class and interface be extended and implemented together?

A subclass can extend only one abstract class but it can implement multiple interfaces. Abstract classes can extend other class and implement interfaces but interface can only extend other interfaces.

Why we need both abstract class and interface?

The short answer: An abstract class allows you to create functionality that subclasses can implement or override. An interface only allows you to define functionality, not implement it. And whereas a class can extend only one abstract class, it can take advantage of multiple interfaces.

Can we inherit abstract class and interface?

An abstract class defines the identity of a class. An interface can inherit multiple interfaces but cannot inherit a class. An abstract class can inherit a class and multiple interfaces.


2 Answers

It's perfectly normal to use these two together. Consider for instance AbstractList (implementing List) and AbstractMap (implementing Map) in the JDK.

My knee-jerk reaction would have been to have the abstract class implement the interface and then have the concrete classes derive from it:

abstract class Base implements TheInterface {
    /* ...shared methods... */
}

class Concrete1 extends Base { }

class Concrete1 extends Base { }

But your question raising the other possibility made me think, and I can't see much of an argument against doing it that way:

abstract class Base {
    /* ...shared methods... */
}

class Concrete1 extends Base implements TheInterface { }

class Concrete1 extends Base implements TheInterface { }

Further, I can see an argument for doing it that way, specifically that it removes the coupling between the abstract class and the interface. If you have another class that needs the functionality Base provides but doesn't need to implement the interface, you have the flexibility to do that.

There's also a third option: Composition. You could not have an abstract class at all, but rather have the multiple concrete classes that implement the interface use a common helper class in their implementation:

class Helper {
    /* ...shared methods... */
}

class Concrete1 implements TheInterface {
    /* ...uses instance of Helper */
}

class Concrete1 implements TheInterface {
    /* ...uses instance of Helper */
}

This has that same flexibility, in another form.

like image 157
T.J. Crowder Avatar answered Sep 25 '22 21:09

T.J. Crowder


I do not think there is a rule of thumb as such. When designing try and follow the SOLID principles to figure out if what you are doing is good or bad. You can find these principles over here. In this particular case, I would think you should ensure you are abiding by the "Open-Close Principle".

like image 22
rgeorge Avatar answered Sep 24 '22 21:09

rgeorge