Бросок затем проверяет или проверяет затем бросок? [дубликат]
5 ответов
Если объект может иметь или не быть того типа, который вам нужен, то как ] (ваш первый метод) лучше по двум причинам:
- Удобство чтения и простота обслуживания: вы указываете тип только один раз
- Производительность: вы выполняете приведение только один раз, а не дважды. (Интересный факт: когда вы используете ключевое слово
is, компилятор C # внутренне переводит его вкак, т.е.coke is Colaэквивалентно(coke as Cola)! = null)
Если объект всегда должен быть запрошенного типа, просто сделайте (Coke) cola и позвольте ему сгенерировать исключение, если это не так.
Я думаю, что это более эффективный 1-й способ: Проведите трансляцию, а затем проверьте , но ...
Много времени вы разрабатываете для разработчиков, и, на мой взгляд, это гораздо более читабельно проверка сначала, а затем приведение ...
Первый (преобразование сначала через as) немного более эффективен, поэтому в этом отношении ~ может быть ~ наилучшей практикой.
Однако в приведенном выше коде, как правило, присутствует некоторый «запах кода». Я бы подумал о рефакторинге любого кода, который следует этому шаблону, если это возможно. Попросите ICola предоставить метод описания и позволить ему описать себя. Это позволяет избежать проверки типов и дублирования кода ...
Позвольте мне просто выложить его там. Но я думаю, что ни то, ни другое не является правильным :) В вашем конкретном примере, зачем вообще иметь интерфейс? Я бы поместил метод «Describe» на ваш интерфейс ICola, а затем реализовал логику описания в ваших классах CocaCola и Pepsi, которые реализуют интерфейс.
Так что в основном поместите это // какой-то уникальный в реализующие классы.
Но чтобы ответить на ваш вопрос, я думаю, что проверка, а затем каст более уместна.
В этом примере используется безопасный локальный параметр, но во многих случаях проверка типа применяется к полям (переменным-членам) класса. В этом случае "as" -then-check безопасно, но "is" -then-cast создает беспричинное состояние гонки.