Why is it preferable to use interfaces instead of abstract classes?

Question

I am not asking about the differences between the two, but why are interfaces more often preferred over abstract classes?

Answer 1

The most obvious “drawback” of abstract classes is that inheriting types can inherit from only one abstract class.

When it comes to interfaces, you can implement several interfaces.

So, when you develop your types, so they need to implement several contracts, interfaces are just the only option.

So, at least in the C # world, this, combined with SOLID principles, can explain the tendency towards interfaces.

Answer 2

I'm going to play here Devil's Advocate ...

The advantage of ABC is that you can add methods to ABC without parsing all the derived classes. If you add a method to an interface, you break up each class that implements this interface.

The Microsoft Council supports classes on interfaces for this reason.

In addition, ABC can provide a default implementation for its methods when necessary.

In addition, ABC can define types (such as enumerations) and readonly 'constants', while an interface cannot.

Answer 3

This is a really busy question. They both have their application in different situations.

Abstract classes

The Abstract class is used when there are common functionalities between subclasses, but the superclass itself will never exist. For example, the Person class will never exist. However, the Woman class will be. Instead of repeating all the methods that are in Woman , in Man , Boy and Girl , we simply cast it into a superclass so that they all have access to this functionality and can override the methods that they want to perform differently.

Interfaces

Interfaces are used when there is a requirement. The way I look at them is like a contract. The convention is that any class that implements the Interface will need to provide code for a certain number of methods.

For example, class A Rock and class Ball can be thrown away. Instead of a ball-throwing method that every object that can be thrown should take into account if each object implements the ThrowingItem interface (I did not want to use the word Throwable for obvious reasons), then the method can simply accept an object of the ThrowingItem type and knows for sure that the agreed methods will be there.

This provides a weak connection between the throw method and the classes that use it, since all interaction is done through the interface.

---

As you can see, two different types are used in completely different situations, and comparing them is like comparing apples and oranges.

Change: I have had some time to think about the ABCs in the last few years.

Over the past few years, there has not been a single case where I needed to use inheritance in my production code. Inheritance becomes difficult to test with abstract classes. How do you test an abstract class? You cannot create an instance of it and create an instance of a subclass if these methods were overridden in a polymorphic way.

Instead, I spent all my time writing. This has led to the emergence of small sole responsibility services that are very easy to verify. So, as a rule, composition over inheritance.

Answer 4

As a rule, we use interfaces when we have nothing to say about the implementation and abstract classes, when we have at least a partial implementation.

Answer 5

Here is my rule of thumb, with which I have found most to agree with:

• Start with a specific class. There is no need to abstract anything if it is never needed.
• Go to the abstraction if you find the right one.

Once you go to the abstraction, you can decide what type with this note: you cannot inherit from several abstract classes, so you must really decide between the abstract class or IMO interface if you need an implementation or not (if not, then just use the interface to avoid collisions with multiple inheritance later)

Answer 6

If you have a type that can be designed as an interface or an abstract class, why do you choose an abstract class?

In this sense, we use only an abstract class when some functions cannot be executed in the interface:

• state. although an interface may request subclasses to implement state, it would be more convenient to use an abstract superclass to hold state.

• limiting member access to protected . and all interface elements are public

• static methods. (note that in Java 8, perhaps the interface may have static methods)

• specific methods with implementations. (note that in Java 8, interface methods may have a defualt impl)

• add more specific methods without parsing subclasses. (note that in Java 8 we can add additional methods to the existing interface if the methods have default values)