Czy warto używać „as” zamiast rzutowania, nawet jeśli nie ma kontroli zerowej? [Zamknięte]

Na blogach programistycznych, przykładach kodu online, a ostatnio nawet w książce, wciąż się potykam o kod:

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

lub, co gorsza:

(x as T).SomeMethod();

To nie ma dla mnie sensu. Jeżeli jesteś pewien, że xjest typu T, należy użyć bezpośredniego obsady: (T)x. Jeśli nie masz pewności, możesz użyć, asale musisz sprawdzić nullprzed wykonaniem jakiejś operacji. Wszystko, co robi powyższy kod, polega na przekształceniu (użytecznego) InvalidCastExceptionw (bezużyteczne) NullReferenceException.

Czy jestem jedynym, który uważa, że ​​to rażące nadużycie assłowa kluczowego? Czy może przeoczyłem coś oczywistego i powyższy wzór ma sens?

Twoje zrozumienie jest prawdziwe. To brzmi jak próba mikrooptymalizacji. Powinieneś użyć normalnej obsady, gdy masz pewność co do typu. Oprócz generowania bardziej sensownego wyjątku, również szybko zawiedzie. Jeśli mylisz o swoim założeniu o rodzaju, program nie będzie natychmiast i będziesz mógł zobaczyć przyczynę awarii od razu, zamiast czekać na NullReferenceExceptionlub ArgumentNullExceptionlub nawet kiedyś logicznego błędu w przyszłości. Ogólnie rzecz biorąc, aswyrażenie, po którym nie następuje nullsprawdzenie, to zapach kodu.

Z drugiej strony, jeśli nie masz pewności co do rzutu, powinieneś użyć aszamiast normalnego rzutu owiniętego try-catchblokiem. Ponadto zaleca się użycie aszamiast kontroli typu, a następnie rzutowania. Zamiast:

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

który generuje isinstinstrukcję dla issłowa kluczowego i castclassinstrukcję dla obsady (skutecznie wykonując rzut dwukrotnie), powinieneś użyć:

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

To tylko generuje isinstinstrukcję. Pierwsza metoda ma potencjalną wadę w aplikacjach wielowątkowych, ponieważ warunek wyścigu może spowodować, że zmienna zmieni swój typ po ispomyślnym sprawdzeniu i nie powiedzie się na linii rzutowania. Druga metoda nie jest podatna na ten błąd.

_{Poniższe rozwiązanie nie jest zalecane do użycia w kodzie produkcyjnym. Jeśli naprawdę nie znosisz tak fundamentalnej konstrukcji w języku C #, możesz rozważyć przejście na VB lub inny język.}

Jeśli ktoś desperacko nienawidzi składni obsady, może napisać metodę rozszerzenia naśladującą obsadę:

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

i użyj ładnej składni [?]:

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

IMHO, aspo prostu sens w połączeniu z nullczekiem:

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

Użycie „as” nie stosuje konwersji zdefiniowanych przez użytkownika, a obsada użyje ich w stosownych przypadkach. W niektórych przypadkach może to być istotna różnica.

Tutaj napisałem o tym trochę:

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

Rozumiem twój punkt widzenia. I zgadzam się z tym, co mówi: operator rzutowania komunikuje „Jestem pewien, że ten obiekt można przekonwertować na ten typ i jestem gotów zaryzykować wyjątek, jeśli się mylę”, podczas gdy operator „as” komunikuje się „Nie jestem pewien, czy ten obiekt można przekonwertować na ten typ; jeśli mam rację, daj mi wartość zerową”.

Istnieje jednak subtelna różnica. (x jako T). Cokolwiek () komunikuje „Wiem nie tylko, że x można przekonwertować na T, ale ponadto, że robi to tylko konwersje odniesienia lub rozpakowania, a ponadto, że x nie jest zerowy”. To komunikuje inne informacje niż ((T) x). Cokolwiek () i być może właśnie tego zamierza autor kodu.

Często widziałem odniesienia do tego wprowadzającego w błąd artykułu jako dowodu, że „as” jest szybsze niż casting.

Jednym z bardziej oczywistych wprowadzających w błąd aspektów tego artykułu jest grafika, która nie wskazuje na to, co jest mierzone: podejrzewam, że mierzy nieudane rzuty (gdzie „as” jest oczywiście znacznie szybsze, ponieważ nie jest zgłaszany żaden wyjątek).

Jeśli poświęcisz czas na wykonanie pomiarów, zobaczysz, że rzutowanie jest, jak można się spodziewać, szybsze niż „as”, gdy rzutowanie się powiedzie.

Podejrzewam, że może to być jeden z powodów użycia „kultowego ładunku” słowa kluczowego zamiast obsady.

Bezpośrednia obsada wymaga pary nawiasów więcej niż assłowa kluczowego. Więc nawet w przypadku, gdy masz 100% pewności, jaki jest typ, zmniejsza to bałagan wizualny.

Zgodziłem się jednak co do wyjątku. Ale przynajmniej dla mnie większość zastosowań assprowadza się do sprawdzenia nullpóźniej, co wydaje mi się lepsze niż wyłapanie wyjątku.

99% czasu, kiedy używam „as”, ma miejsce, gdy nie jestem pewien, jaki jest rzeczywisty typ obiektu

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

i nie chcę wychwytywać jawnych wyjątków rzutowania ani podwójnie rzucać, używając „is”:

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

To dlatego, że ludziom podoba się to, jak wygląda, jest bardzo czytelny.

Spójrzmy prawdzie w oczy: operator rzutowania / konwersji w językach podobnych do C jest dość straszny, jeśli chodzi o czytelność. Wolałbym, żeby C # przyjął albo składnię JavaScript:

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

Lub zdefiniuj tooperator, będący odpowiednikiem rzutowania as:

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

Ludzie astak bardzo lubią , ponieważ dzięki temu czują się bezpieczni od wyjątków ... Jak gwarancja na pudełku. Facet kładzie na pudełku fantazyjną gwarancję, ponieważ chce, żebyś poczuł w sobie ciepło i ciepło. Myślisz, że włożyłeś w nocy to małe pudełko pod poduszkę, Wróżka Gwarancyjna może zejść i opuścić kwaterę, mam rację Ted?

Wracając do tematu ... gdy używasz rzutowania bezpośredniego, istnieje możliwość wystąpienia niepoprawnego wyjątku rzutowania. Tak więc ludzie stosują się asjako ogólne rozwiązanie wszystkich swoich potrzeb castingowych, ponieważ as(samo w sobie) nigdy nie zgłasza wyjątku. Ale zabawną rzeczą jest to, że w przykładzie, który podałeś (x as T).SomeMethod();, wymieniasz niepoprawny wyjątek rzutowania na wyjątek zerowy. Co zaciemnia prawdziwy problem, gdy widzisz wyjątek.

Na ogół nie używam aszbyt wiele. Wolę istest, ponieważ dla mnie wydaje się bardziej czytelny i ma więcej sensu niż próba obsady i sprawdzenie, czy nie ma nic.

To musi być jeden z moich najlepszych pomysłów .

D & E Stroustrup i / lub jakiś post na blogu, którego nie mogę teraz znaleźć, omawia pojęcie tooperatora, który zająłby się kwestią przedstawioną przez https://stackoverflow.com/users/73070/johannes-rossel (tj. Taką samą składnią jak asz DirectCastsemantyką ).

Powodem, dla którego ta implementacja nie została wdrożona, jest to, że obsada powinna powodować ból i być brzydka, więc zostaniesz odepchnięty od korzystania z niej.

Szkoda, że ​​„sprytni” programiści (często autorzy książek (Juval Lowy IIRC)) omijają to, nadużywając asw ten sposób (C ++ nie oferuje as, prawdopodobnie z tego powodu).

Nawet VB ma większą spójność posiadające jednolitą składnię, że zmusza do wyboru TryCastalbo DirectCasti uzupełnić swój umysł !

Uważam, że to assłowo kluczowe może być uważane za bardziej elegancką wersję dynamic_castC ++.

Prawdopodobnie jest bardziej popularny bez powodu technicznego, ale dlatego, że jest łatwiejszy do odczytania i bardziej intuicyjny. (Nie mówię, że dzięki temu lepiej jest po prostu odpowiedzieć na pytanie)

Jednym z powodów używania „jako”:

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

Zamiast (zły kod):

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