If an abstract class does not have fields. Should it be made into an interface? Why ObjectPool is not?

[zms9110750]

https://github.com/dotnet/aspnetcore/blob/8486d31e24f30e3fa1809a95699a0adc16f448d7/src/ObjectPool/src/ObjectPool.cs

Is this some kind of historical legacy, or is there indeed a design concept that I don't know about?

[bartonjs]

Classes can gain new members version to version. Interfaces, for the most part, can't. (Default Interface Methods change this slightly, but not fully).

Framework Design Guidelines recommend abstract classes over interfaces, unless you have a really good reason for an interface.

[zms9110750]

Do you have a link to mention this point? Or a more detailed example.

[bartonjs]

https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/interface ends with

Except for the situations described in these guidelines, you should, in general, choose classes rather than interfaces in designing managed code reusable libraries.

Section 4.3 of Framework Design Guidelines, 3rd edition (and probably 2nd as well) is "Choosing Between Class and Interface", it's about 9 pages long. But the relevant bullets:

• DO favor defining classes over interfaces.
• DO use abstract classes instead of interfaces to decouple the contract from implementations.
• DO define an interface if you need to provide a polymorphic hierarchy of value types.
• CONSIDER defining interfaces to achieve a similar effect to that of multiple inheritance.