c# - operator - Emitir luego verificar o verificar y luego lanzar?
casting de objetos en c# (5)
Posible duplicado:
Casting vs usando la palabra clave ''como'' en el CLR
¿Qué método se considera mejor práctica?
¿Cast primero?
public string Describe(ICola cola)
{
var coke = cola as CocaCola;
if (coke != null)
{
string result;
// some unique coca-cola only code here.
return result;
}
var pepsi = cola as Pepsi;
if (pepsi != null)
{
string result;
// some unique pepsi only code here.
return result;
}
}
¿O debería verificar primero, lanzar más tarde?
public string Describe(ICola cola)
{
if (cola is CocaCola)
{
var coke = (CocaCola) cola;
string result;
// some unique coca-cola only code here.
return result;
}
if (cola is Pepsi)
{
var pepsi = (Pepsi) cola;
string result;
// some unique pepsi only code here.
return result;
}
}
¿Puedes ver alguna otra forma de hacer esto?
Creo que es más eficiente. Primera forma: lanzar y luego verificar , pero ...
Mucho tiempo que desarrollas para los desarrolladores, y en mi opinión, es mucho más fácil de verificar primero y luego de emitir ...
Déjame ponerlo ahí afuera. Pero creo que ninguno está bien :) En tu ejemplo particular, ¿por qué tener una interfaz entonces? Pondría un método de "Describir" en su interfaz ICola, luego implementaría la lógica de descripción en sus clases CocaCola y Pepsi que implementan la interfaz.
Así que, básicamente, pongo ese // some unique <some cola> only code here.
en las clases de implementación.
Pero para responder a su pregunta, creo que Check-then-cast es más apropiado.
Este ejemplo utiliza un parámetro local que es seguro, pero muchas veces la verificación de tipo se aplica a los campos (variables de miembro) de una clase. En ese caso, "como" -then-check es seguro, pero "is" -entonces-cast crea una condición de carrera gratuita.
La primera (emitir la primera vía como) es ligeramente más eficiente, por lo que, en ese sentido, podría ser una mejor práctica.
Sin embargo, el código anterior, en general, muestra un poco de "olor a código". Consideraría refactorizar cualquier código que siga este patrón, si es posible. Haga que ICola
proporcione un método de descripción y permita que se describa a sí mismo. Esto evita las comprobaciones de tipo y el código duplicado ...
Si el objeto puede ser o no del tipo que desea, entonces el operador as
(su primer método) es mejor de dos maneras:
- Legibilidad y facilidad de mantenimiento: solo está especificando el tipo una vez
- Rendimiento: solo estás realizando el reparto una vez, en lugar de dos veces. (Trivia: cuando usas la palabra clave
is
, el compilador de C # la traduce internamenteas
, es decir, elcoke is Cola
es equivalente a(coke as Cola) != null
)
Si el objeto siempre debe ser del tipo solicitado, simplemente haz (Coke)cola
y deja que arroje una excepción si ese no es el caso.