¿Por qué una clase base en C# permite implementar un contrato de interfaz sin heredar de él?

Question

Me he tropezado con esta "característica" de C# - la clase base que implementa métodos de interfaz no tiene que derivar de ella.

Ejemplo:

public interface IContract 
{ 
    void Func(); 
} 

// Note that Base does **not** derive from IContract 
public abstract class Base 
{ 
    public void Func() 
    { 
     Console.WriteLine("Base.Func"); 
    } 
} 

// Note that Derived does *not* provide implementation for IContract 
public class Derived : Base, IContract 
{ 
} 

Lo que pasa es que Derived recoge-mágicamente un método público, Base.Func, y decide que pondrá en práctica IContract.Func.

¿Cuál es el motivo de esta magia?

En mi humilde opinión: esta característica de "casi implementación" es muy poco intuitiva y hace que la inspección del código sea mucho más difícil. ¿Qué piensas?

Answer 1

La razón es que su comentario es simplemente incorrecta:

// Tenga en cuenta que derivó qué no proporcionar implementación para IContract

seguro que lo hace. Sigue la lógica.

• Derived se requiere para proporcionar un miembro público correspondiente a cada miembro de IContract.
• Todos los miembros heredables de una clase base también son miembros de una clase derivada; esa es la definición de la herencia.
• Por lo tanto, Derived proporciona una implementación para IContract; su miembro heredado es un miembro que cumple con el requisito
• Por lo tanto, no hay ningún error.

esta característica es muy poco intuitivo y crea código de inspección mucho más difícil. ¿Qué piensas?

Creo que no deberías usar la función si no te gusta. Si le resulta confuso y extraño leer el código que usa esta función, anime a sus compañeros de trabajo que usan esta función a dejar de hacerlo.

¿En qué se diferencia esta función de cualquier otra característica en la que se utiliza un método de una clase base de una clase derivada? Hay varias formas diferentes en que un método de una clase base puede usarse o mencionarse en una clase derivada: llamadas a métodos, anulaciones, conversiones de grupos de métodos, etc.

Además, esto es relativamente simple, un caso sencillo. Si realmente quiere quejarse sobre la semántica de la interfaz confusa en C#, me gustaría gastar mi tiempo quejándose de semántica de reimplementación de la interfaz. Esa es la que realmente parece hornear fideos de la gente. Siempre tengo que buscar esa cosa en la especificación para asegurarme de obtener la semántica correcta.

Answer 2

¿Por qué crees que esto es extraño y antinatural? Cada miembro público de la clase base también es un miembro público de la clase derivada. Entonces no hay contradicción aquí. De todos modos, puedes implementar la interfaz explícitamente si quieres.