抽象类和接口在一起？

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

Personally I prefer the statement that an abstract class is a background for other classes, so if three other classes have something common, their common ancestor, the abstract class created only for those three other classes, should provide also code from the interface. This would make the abstract class "complete" (in its way) providing all these properties and methods that the three classes share.

However, it finally makes no difference if all of them would implement the same interface. Making abstract class giving everything that is common is in my opinion a more clear way. It's then easier to compare classes by looking only at this what differs.