Затем вы можете проверить или проверить, затем бросить?

Возможный дубликат:
Кастинг против использования ключевого слова 'as в CLR

Какой метод считается лучшей практикой?

Перенесите сначала?

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;
    }
}

Или сначала я должен проверить, бросить позже?

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;
    }
}

Вы можете увидеть какой-либо другой способ сделать это?

Ответ 1

Если объект может или не может быть того типа, который вам нужен, оператор as (ваш первый метод) лучше двумя способами:

Считываемость и простота обслуживания: вы указываете тип один раз
Производительность: вы выполняете только один раз, а не дважды. (Пути: при использовании ключевого слова is компилятор С# внутренне переводит его на as, то есть. coke is Cola эквивалентно (coke as Cola) != null)

Если объект всегда должен быть запрошенного типа, тогда просто сделайте (Coke)cola и дайте ему исключение, если это не так.

Ответ 2

Первый (кастинг первый через as) немного более эффективен, поэтому в этом отношении он может быть наилучшей практикой.

Однако, код выше, в общем, отображает немного "запаха кода". Я бы подумал о рефакторинге любого кода, который следует за этим шаблоном, если это возможно. Пусть ICola предоставит метод описания и пусть он описывает себя. Это позволяет избежать проверки типа и дублированного кода...

Ответ 3

В этом примере используется локальный параметр, безопасный, но много раз проверка типа применяется к полям (переменным-членам) класса. В этом случае "как" -это-проверка безопасна, но "есть" -то-литье создает безвозмездное состояние гонки.

Ответ 4

Я думаю, что это более эффективный первый способ: Cast, а затем проверить, но...

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

Ответ 5

Позвольте мне просто поместить его там. Но я думаю, что это не так. В вашем конкретном примере, почему у вас вообще есть интерфейс? Я бы предложил метод "Описать" на вашем интерфейсе ICola, а затем реализовать описательную логику в ваших классах CocaCola и Pepsi, которые реализуют интерфейс.

Итак, в основном, это // some unique <some cola> only code here. в классы реализации.

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