Su comprensión es verdadera. Eso suena como tratando de micro-optimizar para mí. Usted debe utilizar un normal fundido cuando se está seguro del tipo. Además de generar más sensible excepción, también falla rápido. Si usted está equivocado acerca de su hipótesis sobre el tipo, el programa fallará inmediatamente y usted será capaz de ver la causa de la falla de inmediato en lugar de esperar que un NullReferenceException o ArgumentNullException o incluso un error lógico en algún momento en el futuro. En general, un as expresión que no es seguido por un null compruebe en algún lugar es un código de olor.
Por otro lado, si usted no está seguro sobre el molde y esperar a fallar, debe utilizar as en lugar de una normal yeso envuelto con un try-catch bloque. Por otra parte, el uso de as se recomienda más de un tipo de verificación seguido por un lanzamiento. En lugar de:
if (x is SomeType)
((SomeType)x).SomeMethod();
que genera un isinst instrucción para la is de palabras clave, y un castclass instrucción para el yeso (de hecho la realización de la fundición de dos veces), se debe usar:
var v = x as SomeType;
if (v != null)
v.SomeMethod();
Esto sólo genera un isinst instrucción. El primer método tiene un potencial defecto en aplicaciones multiproceso como una condición de anticipación podría causar que la variable para cambiar su tipo después de la is de verificación éxito y fracasar en el elenco de la línea. El último método no es propenso a este error.
La siguiente solución es no se recomienda para su uso en el código de producción. Si realmente odio como un elemento esencial de la construcción en C#, usted podría considerar la posibilidad de cambiar a VB o algún otro idioma.
En caso de que uno desesperadamente odia el elenco de la sintaxis, él/ella puede escribir un método de extensión para imitar el elenco:
public static T To<T>(this object o) { // Name it as you like: As, Cast, To, ...
return (T)o;
}
y el uso de una cuidada[?] sintaxis:
obj.To<SomeType>().SomeMethod()
