How do you decide between using an Abstract Class and an Interface? [duplicate]

Answer 1

As @m4bwav notes, the primary difference is that an abstract class can, and often does, provide a default implementation for at least some methods. This allows you to use the abstract class to keep your code DRY (don't repeat yourself), by keeping code common to all classes that inherit from the abstract class in the abstract class itself.

I think it's a false dilemma, though. You don't need to and arguably shouldn't choose between interfaces and abstract classes. In most cases, you would want to define the interface, then have your abstract class provide a default, skeleton implementation if one is required/desired. For me the question would be do I need an interface or an interface and an abstract class rather than an interface or an abstract class. Using the interface decouples your code from any particular implementation, even your abstract class implementation. If you should choose to have an alternate implementation, using the interface would allow this whereas if you only had the abstract class, you'd have to refactor to add the interface later.

The only situation where I can see that providing an interface in such a situation would not be desired is where you want to restrict it so that only your implementation can be used. Using the abstract class and having certain methods be not be virtual would enforce the use of your code in all circumstances where the implementer is deriving from your class.

Answer 2

Abstract classes offer the possibility to implement specific methods and require others to be implemented in the inheriting class. With interfaces, everything has to be implemented in the implementing class.

Answer 3

Use an abstract class if you have some functionality that you want it's subclasses to have. For instance, if you have a set of functions that you want all of the base abstract class's subclasses to have.

Use an interface if you just want a general contract on behavior/functionality. If you have a function or object that you want to take in a set of different objects, use an interface. Then you can change out the object that is passed in, without changing the method or object that is taking it.

Interfaces are typically loose, compared to Abstract classes. You wouldn't want to use interfaces in a situation where you are constantly writing the same code for all of the interface's methods. Use an abstract class and define each method once.

Also, if you are trying to create a specific object inheritance hierarchy, you really wouldn't want to try to do that with just interfaces.

Also, again, in some languages you can only have a single base class, and if an object already has a base class, you are going to have to do some refactoring in order to use an abstract base class. This may or may not mean that you might want to use an inteface instead.

As @tvanfosson notes, it's not a bad idea to use a lot of interfaces, when you really understand abstract classes and interfaces, it's not really an either/or situation. A particular situation could use both abstract classes and interfaces or neither. I like to use interfaces sometimes simply to restrict what a method or object can access on a passed in parameter object.