Имеет ли смысл использовать «как» вместо приведения, даже если нет нулевой проверки? [закрыто]

В блогах по разработке, онлайн-примерах кода и (в последнее время) даже в книге я постоянно спотыкаюсь о коде:

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

или, что еще хуже:

(x as T).SomeMethod();

Это не имеет смысла для меня. Если вы уверены , что xэто типа T, вы должны использовать прямой бросок: (T)x. Если вы не уверены, вы можете использовать, asно нужно проверить nullперед выполнением какой-либо операции. Все, что делает приведенный выше код, это превращает (полезное) InvalidCastExceptionв (бесполезное) NullReferenceException.

Я единственный, кто считает, что это вопиющее злоупотребление asключевым словом? Или я упустил что-то очевидное, и приведенная выше схема действительно имеет смысл?

Ваше понимание верно. Это звучит как попытка микрооптимизации для меня. Вы должны использовать обычное приведение, когда вы уверены в типе. Помимо генерации более разумного исключения, оно также быстро дает сбой. Если вы ошибаетесь в своем предположении о типе, ваша программа немедленно завершится сбоем, и вы сможете сразу увидеть причину сбоя, а не ждать NullReferenceExceptionили ArgumentNullExceptionдаже логической ошибки в будущем. Как правило, asвыражение, за которым не следует nullпроверка, является запахом кода.

С другой стороны, если вы не уверены в касте и ожидаете, что он потерпит неудачу, вы должны использовать asвместо обычного броска, обернутого try-catchблоком. Кроме того, asрекомендуется использование над проверкой типа, сопровождаемой приведением. Вместо:

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

который генерирует isinstинструкцию для isключевого слова и castclassинструкцию для приведения (эффективно выполняя приведение дважды), вы должны использовать:

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

Это только генерирует isinstинструкцию. У первого метода есть потенциальный недостаток в многопоточных приложениях, так как условие гонки может привести к тому, что переменная изменит свой тип после isуспешной проверки и потерпит неудачу на линии преобразования . Последний метод не подвержен этой ошибке.

_{Следующее решение не рекомендуется для использования в производственном коде. Если вы действительно ненавидите такую ​​фундаментальную конструкцию в C #, вы можете подумать о переходе на VB или другой язык.}

В случае, если кто-то отчаянно ненавидит синтаксис преобразования, он / она может написать метод расширения для имитации преобразования:

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

и используйте аккуратный синтаксис [?]:

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

ИМХО, asпросто имеет смысл в сочетании с nullпроверкой

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

Использование «как» не применяет определенные пользователем преобразования, в то время как приведение будет использовать их там, где это необходимо. Это может быть важным отличием в некоторых случаях.

Я написал немного об этом здесь:

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

Я понимаю вашу точку зрения. И я согласен с этим: оператор приведения сообщает: «Я уверен, что этот объект может быть преобразован в этот тип, и я готов рискнуть исключением, если ошибаюсь», тогда как оператор «как» сообщает «Я не уверен, что этот объект можно преобразовать в этот тип; если я ошибаюсь, дайте мне ноль».

Тем не менее, есть небольшая разница. (x как T). Что бы ни () сообщало: «Я знаю не только то, что x можно преобразовать в T, но, кроме того, это включает в себя только ссылочные или распаковывающие преобразования, и, кроме того, что x не является нулевым». Это действительно передает информацию, отличную от ((T) x) .Wh независимо (), и, возможно, именно это намеревается автор кода.

Я часто видел ссылки на эту вводящую в заблуждение статью как свидетельство того, что «как» быстрее, чем приведение.

Одним из наиболее очевидных вводящих в заблуждение аспектов этой статьи является график, который не указывает, что измеряется: я подозреваю, что он измеряет неудачные приведения (где «как», очевидно, намного быстрее, поскольку не выбрасывается исключение).

Если вы потратите время на измерения, то увидите, что приведение происходит, как и следовало ожидать, быстрее, чем «как», когда приведение успешно.

Я подозреваю, что это может быть одной из причин "культа груза" использования ключевого слова as вместо приведения.

Прямое приведение требует пары скобок больше, чем asключевое слово. Так что даже в том случае, если вы на 100% уверены, что это за тип, это уменьшает визуальный беспорядок.

Договорились об исключении, хотя. Но, по крайней мере, для меня, большинство применений asсводятся к тому, чтобы nullпотом проверить , что для меня лучше, чем поймать исключение.

99% времени, когда я использую «как», это когда я не уверен, какой тип объекта на самом деле

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

и я не хочу ни отлавливать явные исключения приведения, ни делать приведения дважды, используя «is»:

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

Это просто потому, что людям нравится, как это выглядит, это очень читабельно.

Посмотрим правде в глаза: оператор приведения / преобразования в C-подобных языках довольно ужасен с точки зрения читаемости. Я хотел бы лучше, если бы C # принял любой синтаксис Javascript:

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

Или определите toоператор, эквивалент преобразования as:

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

Людям asтак нравится, потому что это заставляет их чувствовать себя в безопасности от исключений ... Как гарантия на коробке. Парень ставит на коробку причудливую гарантию, потому что хочет, чтобы внутри вас было тепло и жарко. Вы полагаете, что положили эту маленькую коробочку под подушку ночью, Фея Гарантии может спуститься и уйти через четверть, я прав, Тед?

Вернемся к теме ... при использовании прямого приведения существует вероятность недопустимого исключения приведения. Таким образом, люди применяют asв качестве общего решения для всех своих потребностей в кастинге, потому что as(само по себе) никогда не вызовут исключения. Но забавно то, что в приведенном вами примере (x as T).SomeMethod();вы заменяете недопустимое исключение приведения на исключение нулевой ссылки. Что скрывает реальную проблему, когда вы видите исключение.

Я обычно не использую asслишком много. Я предпочитаю isтест, потому что для меня он кажется более читабельным и имеет больше смысла, чем попытка приведения и проверка на ноль.

Это должно быть одним из моих главных раздражителей .

D & E Страуструпа и / или какой-то пост в блоге, который я не могу найти прямо сейчас, обсуждает понятие toоператора, который бы обращал внимание на точку зрения https://stackoverflow.com/users/73070/johannes-rossel (т. Е. Тот же синтаксис, что и asс DirectCastсемантикой ).

Причина, по которой это не было реализовано, заключается в том, что приведение должно причинять боль и быть уродливым, поэтому вы отталкиваетесь от его использования.

Жаль, что «умные» программисты (часто авторы книг (Ювал Лоуи IIRC)) обходят это, злоупотребляя asэтим способом (C ++ не предлагает as, вероятно, по этой причине).

Даже VB обладает большей последовательностью, имея единый синтаксис, который заставляет вас выбирать « TryCastили» DirectCastи принимать решение !

Я считаю, что это asключевое слово можно считать более элегантно выглядящей версией dynamic_castиз C ++.

Вероятно, он более популярен не по техническим причинам, а только потому, что его легче читать и он более интуитивно понятен. (Не говорю, что это лучше, просто пытаясь ответить на вопрос)

Одна из причин использования «как»:

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

Вместо (плохой код):

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