¿Por qué no hay error de compilación cuando lanzo una clase a una interfaz que no implementa?

Question

Si intento una conversión inválida de una clase a una interfaz, entonces el compilador no se queja (el error ocurre en tiempo de ejecución); hace quejarse, sin embargo, si intento un lanzamiento similar a una clase abstracta.

class Program 
{ 
    abstract class aBaz 
    { 
     public abstract int A { get; } 
    } 

    interface IBar 
    { 
     int B { get; } 
    } 

    class Foo 
    { 
     public int C { get; } 
    } 

    static void Main() 
    { 
     Foo foo = new Foo(); 

     // compiler error, as expected, since Foo doesn't inherit aBaz 
     aBaz baz = (aBaz)foo; 

     // no compiler error, even though Foo doesn't implement IBar 
     IBar bar = (IBar)foo; 
    } 
} 

¿por qué el compilador rechazan el reparto de Foo a IBar, cuando es (aparentemente?) No es válida? O, para voltear la pregunta, si el compilador permite este lanzamiento "no válido" a la interfaz IBar, ¿por qué no permite el molde "inválido" similar a la clase abstracta aBaz?

Answer 1

Debes entender el sistema de herencia de .Net para ver por qué esto tiene sentido. En .Net, una clase puede heredar solo de una clase base pero puede implementar cualquier cantidad de interfaces.

class Program 
{ 
    abstract class aBaz 
    { 
     public abstract int A { get; } 
    } 

    interface IBar 
    { 
     int B { get; } 
    } 

    class Foo 
    { 
     public int C { get; } 
    } 

    class BarableFoo : Foo, IBar 
    { 
     public int C { get; } 
    } 

    static void Main() 
    { 
     // This is why the compiler doesn't error on the later cast 
     Foo foo = new BarableFoo(); 

     // compiler error: aBaz is a class and the compiler knows that 
     // Foo is not a _subclass_ of aBaz. 
     aBaz baz = (aBaz)foo; 

     // no compiler error: the class Foo does not implement IBar, however at runtime 
     // this instance, "foo", might be a subclass of Foo that _implements_ IBar. 
     // This is perfectly valid, and succeeds at runtime. 
     IBar bar = (IBar)foo; 

     // On the other hand... 
     foo = new Foo(); 

     // This fails at runtime as expected. 
     bar = (IBar)foo; 
    } 

} 

En el ejemplo original, extremadamente simple en la pregunta, parece que el compilador podría detectar que esta instancia de foo nunca va a poder convertir al IBar, sino que es más bien un "bueno tener" advertencia que una cuestión de corrección del lenguaje.

Answer 2

El objetivo de un molde es suprimir el error del compilador.
(por ejemplo, si se sabe que foo es realmente una instancia de un subtipo que no implementa la interfaz)

Si el compilador puede demostrar que es imposible que el molde tenga éxito, todavía dará un error. (por ejemplo, si lo lanzas a una clase que no se encuentra en su jerarquía)

Answer 3

Y para demostrar que el compilador no es tonto no es el caso actulaly cuando conversión fallará en tiempo de compilación: si compilador puede probar que no hay otras clases pueden derivar de la clase se producirá un error de lanzamiento a las interfaces en tiempo de compilación:

sealed class NoBar 
{ 
} 

struct NoBarValue 
{ 
} 

IBar noBar = (IBar)(new NoBar()); // fails at compile time 
IBar noBarValue = (IBar)(new NoBarValue()); // fails at compile time 

En el primer caso (NoBar) la clase está explícitamente sellada (y por lo tanto no hay clases derivadas que puedan implementar IFoo) y el compilador sabe que no implementa IBar, por lo que puede fallar en tiempo de compilación. El segundo caso (NoBarValue) es similar, con la única diferencia de que los tipos de valores (struct) están sellados implícitamente.