Is there a benefit to having both an abstract class and an interface?

Question

I started out with a generic interface called ILogin. The interfaces requires that you implement two properties: UserID and Password. I have many login-type classes that implement this interface. As my project grew and grew, I found that many classes repeated the UserID and Password code. Now I decide that I need a base Login class.

Is it proper to create an abstract base Login class that implements the ILogin interface and have all of my concrete classes just inherit from the abstract class and override when necessary? Originally I was thinking there would be no problem with this. Then I started think that ILogin was probably unneeded because it'll likely only ever be implemented by my abstract class.

Is there a benefit to keeping both the abstract class and the interface around?

Thanks!

Answer 1

If the abstract class has functionality, it is wise to keep it. But if it only contains abstract methods and no fields. I see no use in keeping both.

Edit: I work on legacy code with lots of abstract classes. If I ever have the time, I will add the interfaces, (and possibly remove the empty abstracts). Because working with interfaces greatly enhances the possibilities. And they honour their name by exactly defining the interface.

Answer 2

I usually code against abstract classes when it makes sense and implement (and create in an external contracts assembly/library) an interface in every class (abstract or not) so I can more easily implement Windows Communication Foundation or inversion of control when necessary (which is almost always for mocking). This has become second nature for me.

Answer 3

Absolutely. The interface is always the correct way to go--that way anything can implement it (including something that already has a parent).

The abstract class tends to make it so you don't have to reimplement some pieces of that functionality. Swing uses it a bit, they will have an interface and then a default implementation for you to override just one of the 5 methods or it might take care of adding listeners for you, but you don't have to use that base class if you don't want to.

Answer 4

If your abstract class is the only class that will ever implement the interface, then you can always just check for instances of the abstract class, you don't need the interface. But if you want to be future-compatible with new classes not yet written which will not extend the abstract class but could use the interface, then keep using the interface now.

Answer 5

I agree with cfeduke. I ALWAYS start with interfaces and in the past have used abstract classes that implement interfaces and provide basic functionality to promote code reuse among the classes that inherit from the abstract class. Mocking and IOC are generally speaking interface dependent, for this reason alone I would use interfaces in my designs.

Answer 6

I would always advise that you use interfaces. Abstract classes have the advantage that you can add in default functionality, but requiring that a user use their single inheritance is pretty aggressive.

Microsoft class libraries favour abstract classes over interfaces in a number of cases because it enables them to modify the underlying class. Adding a method to an abstract class rarely breaks someone who inherits from it. Adding a method to an interface always breaks its implementors. However, this provides one of the best reasons for using interfaces: the awful possibility that Microsoft may have already used up your one inheritance.

I would suggest, however, that in your particular case you may wish to revisit the design pattern you are using. It seems unusual to have a lot of "logon-type" classes.

Answer 7

I think a benefit of keeping the interface would be the ability for future classes to implement multiple interfaces whereas a class can only inherit from one abstract class.

You could extend the functionality of subclasses by creating a new Interface with a different set of methods.

Answer 8

Definitely. Let's think of a concrete example.

Say we have an abstract class Animal. Say, we make some subclasses Cat, Dog, Mosquito, and Eagle. We can implement its Eat(), Breathe(), Sleep() methods of the abstract class Animal.

So far, so good. Now, let's say we want to have the Fly() method for the Mosquito and Eagle classes. Since these two organisms aren't really well-related (one is a bird, another is an insect) it wouldn't be easy to come up with a common ancestor for the two that we can have as an abstract class. This would best be implemented by an interface IFly.

The IFly interface can have a Fly() method to be implemented. Both Mosquito and Eagle classes can both be subclasses of the abstract class Animal and implement the interface IFly and be able to Eat(), Breathe(), Sleep() and Fly() without having some type of odd ancenstral relationship between the two classes.

Answer 9

Your interface defines the contract that must be fulfilled for the object to be accepted; your abstract class defines the contract that must be fulfilled AND defines some specific implementation details.

Think of it this way; if you think it's ever possible for anyone to want to fulfill that contract in a different way than the way that the abstract class sketches out (say, with a different backing datatype implementation), then you should have both the interface and the abstract class that implements that.

There's almost no overhead involved in having both the abstract class and the interface; your risk with that approach primarily involves a later coder coming across the interface, not realizing that there's an abstract class that implements the interface, and creating an entire implementation from scratch where it doesn't need to be. I would say that this could be gotten around by specifying in your interface documentation that there is a "default" implementation of the interface in your abstract class; while some coding standards may frown on that practice, I don't see any real problems with it.

Answer 10

Assuming you are asking specifically when the interface and the abstract class have identical signatures ...

... (If the members of the Interface are different in any way from the members of the abstract class then of course the answer is yes, there may be a need for both)

... but assuming the members are identical, then the only reason I can think of to need both is if you're coding in a system that does not allow multiple implementation inheritance there are two classes in your system that need to be polymorphically similar, but must inherit from different base classes...