¿Tiene sentido usar "como" en lugar de un lanzamiento, incluso si no hay un cheque nulo? [cerrado]

En blogs de desarrollo, ejemplos de código en línea e (recientemente) incluso un libro, sigo tropezando con código como este:

var y = x as T;
y.SomeMethod();

o, peor aún:

(x as T).SomeMethod();

Eso no tiene sentido para mí. Si está seguro de que xes de tipo T, se debe utilizar un molde directo: (T)x. Si no está seguro, puede usarlo, aspero debe verificarnull antes de realizar alguna operación. Todo lo que hace el código anterior es convertir un (útil) InvalidCastExceptionen un (inútil) NullReferenceException.

¿Soy el único que piensa que esto es un abuso flagrante de la aspalabra clave? ¿O me perdí algo obvio y el patrón anterior realmente tiene sentido?

Tu comprensión es verdadera. Eso suena como tratar de micro-optimizar para mí. Debe usar un yeso normal cuando esté seguro del tipo. Además de generar una excepción más sensata, también falla rápidamente. Si se equivoca sobre su hipótesis sobre el tipo, el programa fallará inmediatamente y usted será capaz de ver la causa del fracaso de inmediato en lugar de esperar a que una NullReferenceExceptiono ArgumentNullExceptionni siquiera un error lógico en algún momento en el futuro. En general, una asexpresión que no es seguida por un nullcheque en alguna parte es un olor a código.

Por otro lado, si no está seguro sobre el yeso y espera que falle, debe usarlo en aslugar de un yeso normal envuelto con un try-catchbloque. Además, asse recomienda el uso de una verificación de tipo seguida de un yeso. En vez de:

if (x is SomeType)
   ((SomeType)x).SomeMethod();

que genera una isinstinstrucción para la ispalabra clave y una castclassinstrucción para el reparto (realizar efectivamente el reparto dos veces), debe usar:

var v = x as SomeType;
if (v != null)
    v.SomeMethod();

Esto solo genera una isinstinstrucción. El primer método tiene una falla potencial en aplicaciones de subprocesos múltiples, ya que una condición de carrera puede hacer que la variable cambie su tipo después de que la isverificación se haya realizado correctamente y falle en la línea de lanzamiento. El último método no es propenso a este error.

_{La siguiente solución no se recomienda para su uso en el código de producción. Si realmente odias una construcción tan fundamental en C #, podrías considerar cambiar a VB u otro lenguaje.}

En caso de que uno odie desesperadamente la sintaxis del elenco, 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 use una sintaxis ordenada [?]:

obj.To<SomeType>().SomeMethod()

En mi humilde opinión, astiene sentido cuando se combina con un nullcheque:

var y = x as T;
if (y != null)
    y.SomeMethod();

El uso de 'as' no aplica las conversiones definidas por el usuario, mientras que el elenco las usará cuando corresponda. Esa puede ser una diferencia importante en algunos casos.

Escribí un poco sobre esto aquí:

http://blogs.msdn.com/ericlippert/archive/2009/10/08/what-s-the-difference-between-as-and-cast-operators.aspx

Entiendo tu punto. Y estoy de acuerdo con el objetivo: que un operador de reparto comunica "Estoy seguro de que este objeto se puede convertir a ese tipo, y estoy dispuesto a arriesgar una excepción si me equivoco", mientras que un operador "como" se comunica "No estoy seguro de que este objeto se pueda convertir a ese tipo; dame un valor nulo si me equivoco".

Sin embargo, hay una sutil diferencia. (x como T). Lo que sea que () comunique "Sé no solo que x puede convertirse en una T, sino que, además, eso implica solo conversiones de referencia o unboxing y, además, que x no es nulo". Eso comunica información diferente a ((T) x). Lo que sea (), y quizás eso es lo que pretende el autor del código.

A menudo he visto referencias a este artículo engañoso. como evidencia de que "as" es más rápido que el casting.

Uno de los aspectos engañosos más obvios de este artículo es el gráfico, que no indica lo que se está midiendo: sospecho que la medición ha fallado lanzamientos (donde "as" es obviamente mucho más rápido ya que no se produce ninguna excepción).

Si se toma el tiempo para hacer las mediciones, verá que el lanzamiento es, como era de esperar, más rápido que "como" cuando el lanzamiento tiene éxito.

Sospecho que esta puede ser una razón para el uso de "culto de carga" de la palabra clave como en lugar de un elenco.

El reparto directo necesita un par de paréntesis más que la aspalabra clave. Entonces, incluso en el caso de que esté 100% seguro de cuál es el tipo, reduce el desorden visual.

Sin embargo, estuvo de acuerdo en lo de la excepción. Pero al menos para mí, la mayoría de los usos de asreducir se reducen para verificar nulldespués, lo que me parece más agradable que detectar una excepción.

El 99% de las veces que uso "como" es cuando no estoy seguro de cuál es el tipo de objeto real

var x = obj as T;
if(x != null){
 //x was type T!
}

y no quiero capturar excepciones explícitas ni emitir dos veces, usando "is":

//I don't like this
if(obj is T){
  var x = (T)obj; 
}

Es solo porque a la gente le gusta cómo se ve, es muy legible.

Seamos realistas: el operador de conversión / conversión en lenguajes tipo C es bastante terrible, en cuanto a legibilidad. Me gustaría que C # adoptara la sintaxis Javascript de:

object o = 1;
int i = int(o);

O defina un tooperador, el equivalente de lanzamiento de as:

object o = 1;
int i = o to int;

A la gente le gustaas mucho porque los hace sentir a salvo de las excepciones ... Como garantía en una caja. Un chico pone una garantía elegante en la caja porque quiere que te sientas cálido y tostado por dentro. Crees que pones esa cajita debajo de tu almohada por la noche, el Hada de la Garantía podría bajar y dejar un cuarto, ¿estoy en lo cierto, Ted?

Volviendo al tema ... cuando se usa una transmisión directa, existe la posibilidad de una excepción de transmisión no válida. Por lo tanto, las personas se aplican ascomo una solución general a todas sus necesidades de lanzamiento porque as(por sí solo) nunca arrojará una excepción. Pero lo curioso de eso, está en el ejemplo que diste(x as T).SomeMethod(); , está intercambiando una excepción de conversión no válida por una excepción de referencia nula. Lo que ofusca el verdadero problema cuando ves la excepción.

Generalmente no uso asdemasiado. Prefiero la isprueba porque, para mí, parece más legible y tiene más sentido que probar un yeso y verificar si es nulo.

Este tiene que ser uno de mis principales manías .

D&E de Stroustrup y / o alguna publicación de blog que no puedo encontrar en este momento discute la noción de un tooperador que abordaría el punto hecho por https://stackoverflow.com/users/73070/johannes-rossel (es decir, la misma sintaxis aspero con DirectCastsemántica )

La razón por la que esto no se implementó es porque un yeso debería causar dolor y ser feo, por lo que no podrá usarlo.

Lástima que los programadores 'inteligentes' (a menudo autores de libros (Juval Lowy IIRC)) lo eviten abusando asde esta manera (C ++ no ofrece una as, probablemente por esta razón).

¡Incluso VB tiene más consistencia al tener una sintaxis uniforme que te obliga a elegir un TryCasto DirectCasty tomar una decisión !

Creo que la aspalabra clave podría considerarse como una versión más elegante dynamic_castde C ++.

Probablemente sea más popular sin ninguna razón técnica, sino solo porque es más fácil de leer y más intuitivo. (No decir que lo hace mejor solo tratando de responder la pregunta)

Una razón para usar "como":

T t = obj as T;
 //some other thread changes obj to another type...
if (t != null) action(t); //still works

En lugar de (código incorrecto):

if (obj is T)
{
     //bang, some other thread changes obj to another type...
     action((T)obj); //InvalidCastException
}