Czy ma sens definiowanie interfejsu, jeśli mam już klasę abstrakcyjną?

Mam klasę z pewnymi domyślnymi / współdzielonymi funkcjami. Używam abstract classdo tego:

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);
}

Jak widać, mam również interfejs ITypeNameMapper. Czy zdefiniowanie tego interfejsu ma sens, jeśli mam już klasę abstrakcyjną TypeNameMapperlub abstract classwystarczy?

TypeDefinition w tym minimalnym przykładzie jest również abstrakcyjny.

Tak, ponieważ C # nie zezwala na wielokrotne dziedziczenie oprócz interfejsów.

Więc jeśli mam klasę, która jest zarówno TypeNameMapper, jak i SomethingelseMapper, mogę:

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); }
}

Interfejsy i klasy abstrakcyjne służą różnym celom:

• Interfejsy definiują interfejsy API i należą do klientów, a nie do implementacji.
• Jeśli klasy współużytkują implementacje, możesz skorzystać z klasy abstrakcyjnej .

W twoim przykładzie interface ITypeNameMapperokreśla potrzeby klientów i abstract class TypeNameMappernie dodaje żadnej wartości.

Cała koncepcja interfejsów została stworzona w celu wspierania rodziny klas posiadających wspólne API.

To wyraźnie mówi, że każde użycie interfejsu oznacza (lub oczekuje się, że) będzie więcej niż jedną implementację jego specyfikacji.

Frameworki DI zamulają wody tutaj, ponieważ wiele z nich wymaga interfejsu, chociaż będzie zawsze tylko jedna implementacja - dla mnie jest to nieracjonalne obciążenie ogólne, ponieważ w większości przypadków jest to po prostu bardziej złożony i wolniejszy sposób wywoływania nowego, ale to jest co to jest.

Odpowiedź leży w samym pytaniu. Jeśli masz klasę abstrakcyjną, przygotowujesz się do utworzenia więcej niż jednej klasy pochodnej ze wspólnym interfejsem API. Dlatego użycie interfejsu jest wyraźnie wskazane.

Jeśli chcemy wyraźnie odpowiedzieć na pytanie, autor mówi: „Czy sensowne jest zdefiniowanie tego interfejsu, jeśli mam już klasę abstrakcyjną TypeNameMapper lub klasa abstrakcyjna wystarczy?”

Odpowiedź brzmi: tak i nie - tak, powinieneś utworzyć interfejs, nawet jeśli masz już abstrakcyjną klasę podstawową (ponieważ nie powinieneś odnosić się do abstrakcyjnej klasy bazowej w żadnym kodzie klienta) i nie, ponieważ nie powinieneś był tworzyć abstrakcyjna klasa bazowa przy braku interfejsu.

Oczywiste jest, że nie włożyłeś wystarczającej uwagi w API, które próbujesz zbudować. Najpierw wymyśl interfejs API, a następnie w razie potrzeby zapewnij częściową implementację. Fakt, że twoja abstrakcyjna klasa bazowa sprawdza kod w kodzie, wystarcza, aby powiedzieć, że nie jest to właściwa abstrakcja.

Podobnie jak w większości rzeczy w OOD, kiedy jesteś w ruchu i dobrze wykonujesz swój model obiektowy, twój kod poinformuje cię, co będzie dalej. Zacznij od interfejsu, zaimplementuj ten interfejs w potrzebnych klasach. Jeśli zauważysz, że piszesz podobny kod, wyodrębnij go do abstrakcyjnej klasy bazowej - ważny jest interfejs, abstrakcyjna klasa podstawowa jest tylko pomocnikiem i może istnieć więcej niż jedna.

Odpowiedź na to pytanie jest trudna bez znajomości reszty aplikacji.

Zakładając, że używasz jakiegoś modelu DI i zaprojektowałeś swój kod tak, aby był możliwie jak najbardziej rozszerzalny (abyś mógł TypeNameMapperłatwo dodawać nowe ), powiedziałbym tak.

Powody dla:

• Skutecznie dostajesz go za darmo, ponieważ klasa podstawowa implementuje to interface, czego nie musisz się martwić w żadnych implementacjach potomnych
• Większość frameworków IoC i bibliotek Mocking oczekuje interfaces. Chociaż wiele z nich pracuje z klasami abstrakcyjnymi, nie zawsze jest to pewne i jestem wielkim zwolennikiem podążania tą samą ścieżką, co pozostałe 99% użytkowników biblioteki, tam gdzie to możliwe.

Powody przeciwko:

• Ściśle mówiąc (jak już zauważyłeś) NAPRAWDĘ nie musisz
• Jeśli class/ interfacezmienia się, pojawia się trochę dodatkowego obciążenia

Biorąc wszystko pod uwagę, powiedziałbym, że powinieneś stworzyć interface. Przyczyny są dość znikome, ale chociaż możliwe jest użycie abstrakcji w kpinach i IoC, jest to o wiele łatwiejsze dzięki interfejsom. Ostatecznie jednak nie skrytykowałbym kodu kolegi, gdyby poszedł w drugą stronę.