¿Tiene sentido definir una interfaz si ya tengo una clase abstracta?

Tengo una clase con alguna funcionalidad predeterminada / compartida. Yo uso abstract classpara ello:

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

Como puede ver, también tengo la interfaz ITypeNameMapper. ¿Tiene sentido definir esta interfaz si ya tengo una clase abstracta TypeNameMappero si abstract classes suficiente?

TypeDefinition en este ejemplo mínimo también es abstracto.

Sí, porque C # no permite la herencia múltiple, excepto con interfaces.

Entonces, si tengo una clase que es TypeNameMapper y SomethingelseMapper, puedo hacer:

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

Las interfaces y las clases abstractas tienen diferentes propósitos:

• Las interfaces definen las API y pertenecen a los clientes, no a las implementaciones.
• Si las clases comparten implementaciones, entonces puede beneficiarse de una clase abstracta .

En su ejemplo, interface ITypeNameMapperdefine las necesidades de los clientes y abstract class TypeNameMapperno agrega ningún valor.

Todo el concepto de interfaces fue creado para soportar una familia de clases que tienen una API compartida.

Esto dice explícitamente que cualquier uso de una interfaz implica que hay (o se espera que haya) más de una implementación de su especificación.

Los marcos DI han enturbiado las aguas aquí, ya que muchos de ellos requieren una interfaz a pesar de que solo habrá una implementación; para mí, esta es una sobrecarga irrazonable para lo que en la mayoría de los casos es solo un medio más complejo y más lento de llamar nuevo, pero Es lo que es.

La respuesta está en la pregunta misma. Si tiene una clase abstracta, se está preparando para la creación de más de una clase derivada con una API común. Por lo tanto, el uso de una interfaz está claramente indicado.

Si queremos responder explícitamente a la pregunta, el autor dice: "¿Tiene sentido definir esta interfaz si ya tengo una clase abstracta TypeNameMapper o la clase abstracta es suficiente?"

La respuesta es sí y no: sí, debe crear la interfaz aunque ya tenga la clase base abstracta (porque no debería referirse a la clase base abstracta en ningún código de cliente), y no, porque no debería haber creado la clase base abstracta en ausencia de una interfaz.

Es evidente que no ha pensado lo suficiente en la API que está tratando de construir. Presente primero la API, luego proporcione una implementación parcial si lo desea. El hecho de que su clase base abstracta escriba código de verificación es suficiente para decirle que no es la abstracción correcta.

Como en la mayoría de las cosas en OOD, cuando está en el ritmo y tiene su modelo de objetos bien hecho, su código le informará sobre lo que viene después. Comience con una interfaz, implemente esa interfaz en las clases que la necesite. Si se encuentra escribiendo un código similar, extráigalo en una clase base abstracta: es la interfaz lo que es importante, la clase base abstracta es solo un auxiliar y puede haber más de una.

Esto es bastante difícil de responder sin conocer el resto de la aplicación.

Suponiendo que esté utilizando algún tipo de modelo DI y haya diseñado su código para que sea lo más extensible posible (para que pueda agregar nuevos TypeNameMapperfácilmente), diría que sí.

Razones para:

• Efectivamente lo obtienes de forma gratuita, ya que la clase base implementa interfacelo que no necesitas preocuparte en ninguna implementación secundaria
• La mayoría de los frameworks IoC y las bibliotecas de Mocking esperan interfaces. Si bien muchos de ellos trabajan con clases abstractas, no siempre es un hecho y creo firmemente en seguir el mismo camino que el otro 99% de los usuarios de una biblioteca siempre que sea posible.

Razones contra:

• Estrictamente hablando (como has señalado), REALMENTE no necesitas
• Si el class/ interfacecambia hay un poco de sobrecarga adicional

A fin de cuentas, diría que deberías crear el interface. Las razones en contra son bastante insignificantes, pero, aunque es posible usar resúmenes en burla e IoC, a menudo es mucho más fácil con las interfaces. Sin embargo, en última instancia, no criticaría el código de un colega si fuera por el otro lado.