Ist es sinnvoll, eine Schnittstelle zu definieren, wenn ich bereits eine abstrakte Klasse habe?

Ich habe eine Klasse mit einigen Standard- / gemeinsamen Funktionen. Ich benutze abstract classdafür:

public interface ITypeNameMapper
{
    string Map(TypeDefinition typeDefinition);
}

public abstract class TypeNameMapper : ITypeNameMapper
{
    public virtual string Map(TypeDefinition typeDefinition)
    {
        if (typeDefinition is ClassDefinition classDefinition)
        {
            return Map(classDefinition);
        }
        ...

        throw new ArgumentOutOfRangeException(nameof(typeDefinition));
    }

    protected abstract string Map(ClassDefinition classDefinition);
}

Wie Sie sehen, habe ich auch die Schnittstelle ITypeNameMapper. Ist es sinnvoll, diese Schnittstelle zu definieren, wenn ich bereits eine abstrakte Klasse habe TypeNameMapperoder abstract classgerade genug?

TypeDefinition in diesem minimalen Beispiel ist auch abstrakt.

Ja, da C # die Mehrfachvererbung nur mit Schnittstellen zulässt.

Wenn ich also eine Klasse habe, die sowohl TypeNameMapper als auch SomethingelseMapper ist, kann ich Folgendes tun:

class MultiFunctionalClass : ITypeNameMapper, ISomethingelseMapper 
{
    private TypeNameMapper map1
    private SomethingelseMapper map2

    public string Map(TypeDefinition typeDefinition) { return map1.Map(typeDefintion);}

    public string Map(OtherDef otherDef) { return map2.Map(orderDef); }
}

Schnittstellen und abstrakte Klassen dienen verschiedenen Zwecken:

• Schnittstellen definieren APIs und gehören zu den Clients, nicht zu den Implementierungen.
• Wenn Klassen Implementierungen gemeinsam nutzen, können Sie von einer abstrakten Klasse profitieren .

Definiert in Ihrem Beispiel interface ITypeNameMapperdie Bedürfnisse der Kunden und abstract class TypeNameMapperbietet keinen Mehrwert.

Das gesamte Konzept der Schnittstellen wurde erstellt, um eine Klassenfamilie mit einer gemeinsam genutzten API zu unterstützen.

Dies bedeutet ausdrücklich, dass jede Verwendung einer Schnittstelle impliziert, dass mehr als eine Implementierung ihrer Spezifikation vorhanden ist (oder erwartet wird).

DI-Frameworks haben das Wasser hier getrübt, da viele von ihnen eine Schnittstelle benötigen, obwohl es immer nur eine Implementierung geben wird - für mich ist dies ein unangemessener Aufwand für das, was in den meisten Fällen nur ein komplexeres und langsameres Mittel zum Aufrufen von Neuem ist, aber es es ist was es ist.

Die Antwort liegt in der Frage selbst. Wenn Sie eine abstrakte Klasse haben, bereiten Sie die Erstellung mehrerer abgeleiteter Klassen mit einer gemeinsamen API vor. Somit ist die Verwendung einer Schnittstelle eindeutig gekennzeichnet.

Wenn wir die Frage explizit beantworten möchten, sagt der Autor: "Ist es sinnvoll, diese Schnittstelle zu definieren, wenn ich bereits eine abstrakte Klasse TypeNameMapper habe oder eine abstrakte Klasse gerade ausreicht?"

Die Antwort lautet "Ja" und "Nein". Ja, Sie sollten die Schnittstelle erstellen, obwohl Sie bereits über die abstrakte Basisklasse verfügen (da Sie in keinem Clientcode auf die abstrakte Basisklasse verweisen sollten), und "Nein", weil Sie keine Basisklasse erstellen sollten die abstrakte Basisklasse, wenn keine Schnittstelle vorhanden ist.

Es ist offensichtlich, dass Sie nicht genügend Gedanken in die API gesteckt haben, die Sie erstellen möchten. Überlegen Sie sich zuerst die API und führen Sie dann bei Bedarf eine teilweise Implementierung durch. Die Tatsache, dass Ihre abstrakte Basisklasse Code eincheckt, reicht aus, um Ihnen mitzuteilen, dass es sich nicht um die richtige Abstraktion handelt.

Wie in den meisten OOD-Situationen informiert Sie Ihr Code darüber, was als Nächstes kommt, wenn Sie sich in der Rille befinden und Ihr Objektmodell gut ausgearbeitet haben. Beginnen Sie mit einer Schnittstelle und implementieren Sie diese Schnittstelle in den Klassen, die Sie benötigen. Wenn Sie feststellen, dass Sie ähnlichen Code schreiben, extrahieren Sie ihn in eine abstrakte Basisklasse - es ist die Schnittstelle, die wichtig ist, die abstrakte Basisklasse ist nur ein Helfer, und es kann mehr als einen geben.

Dies ist ziemlich schwierig zu beantworten, ohne den Rest der Anwendung zu kennen.

Angenommen, Sie verwenden ein DI-Modell und haben Ihren Code so erweiterbar wie möglich gestaltet (so dass Sie TypeNameMapperleicht neue hinzufügen können), würde ich Ja sagen.

Gründe für:

• Sie erhalten es praktisch kostenlos, da die Basisklasse das implementiert interface, worüber Sie sich bei untergeordneten Implementierungen keine Gedanken machen müssen
• Die meisten IoC-Frameworks und Mocking-Bibliotheken erwarten interfaces. Obwohl viele von ihnen mit abstrakten Klassen arbeiten, ist dies nicht immer selbstverständlich, und ich bin fest davon überzeugt, dass ich den gleichen Weg wie die anderen 99% der Bibliotheksbenutzer einschlagen werde, wenn dies möglich ist.

Gründe gegen:

• Genau genommen (wie Sie bereits betont haben) müssen Sie das nicht WIRKLICH tun
• Wenn sich das class/ interfaceändert, entsteht ein wenig zusätzlicher Aufwand

Alles in allem würde ich sagen, dass Sie das schaffen sollten interface. Die Gründe dafür sind vernachlässigbar, aber obwohl es möglich ist, Abstracts in Mocking und IoC zu verwenden, ist es mit Interfaces oft viel einfacher. Letztendlich würde ich jedoch den Code eines Kollegen nicht kritisieren, wenn sie den umgekehrten Weg gehen würden.