SOLID Principles : interfaces vs. abstract classes

Question

I have a particular edge case where I'm not sure whether to use an interface or an abstract class. Initially my design used an abstract class where the methods were implemented as protected internal abstract void.

This was useful because I wanted the methods to be callable from within my assembly, but only available through inheritance outside of my assembly.

The problem I encountered was that not all derivatives of the abstract class needed to implement the functionality, so essentially I ended up with empty method bodies.

This is where I had the idea of using interfaces, which meant that I could implement required functionality via the interface, however this meant that the methods would need to be public, and as specified above, I only want the methods to be available through inheritance.

Example using an abstract class:

abstract class Dependency
{
    protected internal abstract void DoThis();
    protected internal abstract void DoThat();
}

sealed class DerivedDependency : Dependency
{
    protected override void DoThis()
    {
        // implementation...
    }

    protected override void DoThat()
    {
        // not required...
    }
}

Example using interfaces:

abstract class Dependency
{
    // whilst this is now empty, it is still required to provide a type hierarchy!
}

interface IDoThis
{
    void DoThis();
}

interface IDoThat
{
    void DoThat();
}

sealed class DerivedDependency : Dependency, IDoThis
{
    public virtual void DoThis()
    {
        // I only need this functionality. I don't need to DoThat();
    }
}

So I am wondering what is better really. Both offer features I want, but it seems that I can't have both.

Do I just put up with having empty method bodies that 3rd parties might implement, not realising they're not meant to be implemented, or, do I implement required functionality only, but risk exposing the functionality via instantiation?

Answer 1

Mentioning solid, what you're missing is Interface Segregation Principle, you should use two interfaces, one for internal consumers (the methods marked as internal) and another for the external ones.

So I would not go for an abstract class nor for an inteface, but for two (or more) interfaces.

Answer 2

I may have found a solution which seems to work nicely, but I would like the communities opinion on whether this abides by or violates SOLID principles:

interface IDoThis
{
    void DoThis();
}

class Dependency : IDoThis
{
    protected internal virtual void DoThis()
    {
        // impl.
    }

    void IDoThis.DoThis()
    {
        this.DoThis();
    }
}

IDoThis idt = new Dependency();
idt.DoThis() // calls into the protected method.

This allows me to segregate functionality via interfaces (ISP), access it publicly within the assembly, and override it in external assemblies (OCP)