Faz sentido usar "como" em vez de um elenco, mesmo que não haja verificação nula? [fechadas]

Em blogs de desenvolvimento, exemplos de código on-line e (recentemente) até um livro, continuo tropeçando em códigos como este:

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

ou ainda pior:

(x as T).SomeMethod();

Isso não faz sentido para mim. Se você tem certeza que xé do tipo T, você deve usar um elenco direta: (T)x. Se você não tiver certeza, pode usá-lo, asmas precisa verificar nullantes de executar alguma operação. Tudo o que o código acima faz é transformar um (útil) InvalidCastExceptionem (inútil) NullReferenceException.

Eu sou o único que acha que isso é um abuso flagrante da aspalavra - chave? Ou eu perdi algo óbvio e o padrão acima realmente faz sentido?

Sua compreensão é verdadeira. Isso parece tentar otimizar para mim. Você deve usar um elenco normal quando tiver certeza do tipo. Além de gerar uma exceção mais sensata, também falha rapidamente. Se você está errado sobre a sua suposição sobre o tipo, o programa irá falhar imediatamente e você será capaz de ver a causa da falha imediatamente em vez de esperar por um NullReferenceExceptionou ArgumentNullExceptionou mesmo um algum erro lógico no futuro. Em geral, uma asexpressão que não é seguida por uma nullverificação em algum lugar é um cheiro de código.

Por outro lado, se você não tem certeza sobre o elenco e espera que ele falhe, use-o em asvez de um elenco normal envolvido com um try-catchbloco. Além disso, asrecomenda-se o uso de uma verificação de tipo seguida por uma conversão. Ao invés de:

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

que gera uma isinstinstrução para a ispalavra - chave e uma castclassinstrução para o elenco (realizando o elenco duas vezes), você deve usar:

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

Isso gera apenas uma isinstinstrução. O método anterior possui uma falha em potencial em aplicativos multithread, pois uma condição de corrida pode fazer com que a variável mude de tipo após a isverificação ser bem-sucedida e falhar na linha de conversão. O último método não é propenso a esse erro.

_{A solução a seguir não é recomendada para uso em código de produção. Se você realmente odeia uma construção fundamental em C #, considere mudar para o VB ou algum outro idioma.}

Caso alguém odeie desesperadamente a sintaxe do elenco, ele / ela pode escrever um método de extensão para imitar o elenco:

public static T To<T>(this object o) { // Name it as you like: As, Cast, To, ...
    return (T)o;
}

e use uma sintaxe pura [?]:

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

IMHO, asapenas faz sentido quando combinado com uma nullverificação:

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

O uso de 'as' não aplica conversões definidas pelo usuário, enquanto o elenco as utilizará quando apropriado. Isso pode ser uma diferença importante em alguns casos.

Eu escrevi um pouco sobre isso aqui:

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

Eu entendo o seu ponto. E eu concordo com o objetivo: que um operador de conversão se comunique "Tenho certeza de que esse objeto pode ser convertido para esse tipo e estou disposto a arriscar uma exceção se estiver errado", enquanto um operador "como" se comunica "Não tenho certeza de que este objeto possa ser convertido para esse tipo; me dê um nulo se estiver errado".

No entanto, há uma diferença sutil. (x como T). O que quer que () comunique "Eu sei não apenas que x pode ser convertido em um T, mas, além disso, que isso envolve apenas conversões de referência ou unboxing e, além disso, que x não é nulo". Isso comunica informações diferentes de ((T) x). Qualquer que seja (), e talvez seja isso que o autor do código pretende.

Eu sempre vi referências a este artigo enganoso como evidência de que "como" é mais rápido que o lançamento.

Um dos aspectos enganosos mais óbvios deste artigo é o gráfico, que não indica o que está sendo medido: suspeito que esteja medindo as projeções com falha (onde "como" é obviamente muito mais rápido, pois nenhuma exceção é lançada).

Se você dedicar algum tempo para fazer as medições, verá que o elenco é, como seria de esperar, mais rápido que "as" quando o elenco é bem-sucedido.

Suspeito que esse seja um dos motivos para o uso de "cult de carga" da palavra-chave as em vez de um elenco.

A conversão direta precisa de um par de parênteses mais do que a aspalavra - chave. Portanto, mesmo no caso de você ter 100% de certeza do tipo, isso reduz a confusão visual.

No entanto, concordamos com a exceção. Mas pelo menos para mim, a maioria dos usos se asresume a procurar nulldepois, o que acho melhor do que pegar uma exceção.

99% do tempo em que uso "como" ocorre quando não tenho certeza de qual é o tipo de objeto real

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

e eu não quero capturar exceções explícitas de elenco nem fazer elenco duas vezes, usando "is":

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

É só porque as pessoas gostam da aparência, é muito legível.

Vamos ser sinceros: o operador de conversão / conversão em idiomas do tipo C é bastante terrível, em termos de legibilidade. Eu gostaria que o C # adotasse a sintaxe Javascript de:

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

Ou defina um tooperador, o equivalente de conversão deas :

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

As pessoas gostam astanto porque as faz se sentirem protegidas de exceções ... Como garantia em uma caixa. Um cara coloca uma garantia chique na caixa, porque ele quer que você se sinta todo quente e quentinho por dentro. Você acha que coloca essa caixinha debaixo do travesseiro à noite, a Fada da Garantia pode descer e deixar um quarto, não é mesmo, Ted?

Voltar ao tópico ... ao usar uma conversão direta, existe a possibilidade de uma exceção de conversão inválida. Portanto, as pessoas se aplicam ascomo uma solução geral para todas as suas necessidades de fundição porque as(por si só) nunca lançará uma exceção. Mas o engraçado é que, no exemplo que você deu(x as T).SomeMethod(); você está trocando uma exceção de conversão inválida por uma exceção de referência nula. O que ofusca o problema real quando você vê a exceção.

Eu geralmente não uso asmuito. Eu prefiro o isteste porque, para mim, parece mais legível e faz mais sentido do que tentar um elenco e verificar se há nulo.

Essa deve ser uma das minhas maiores irritações .

O D&E da Stroustrup e / ou algum post do blog que não consigo encontrar agora discute a noção de tooperador que abordaria o argumento de https://stackoverflow.com/users/73070/johannes-rossel (ou seja, a mesma sintaxe que asmas comDirectCast semântica) )

A razão pela qual isso não foi implementado é porque um elenco deve causar dor e ser feio, para que você se afaste do uso.

Pena que programadores 'inteligentes' (muitas vezes autores de livros (Juval Lowy IIRC)) contornem isso abusando asdessa maneira (o C ++ não oferece as, provavelmente por esse motivo).

Mesmo o VB tem mais consistência em ter uma sintaxe uniforme que o força a escolher um TryCastou DirectCaste decidir-se !

Acredito que a aspalavra - chave possa ser vista como uma versão mais elegante dynamic_castdo C ++.

Provavelmente é mais popular sem motivo técnico, mas apenas porque é mais fácil de ler e mais intuitivo. (Sem dizer que é melhor apenas tentar responder à pergunta)

Um motivo para usar "como":

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

Em vez de (código incorreto):

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