частные проблемы c и частные методы

Question

Привет (снова с философским вопросом),

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

После того, как вы пометите методы как stati c, компилятор будет отправлять не виртуальные сайты вызовов этим участникам. Создание не виртуальных сайтов вызовов предотвратит проверку во время выполнения для каждого вызова, которая гарантирует, что текущий указатель объекта не равен нулю. Это может привести к ощутимому приросту производительности для чувствительного к производительности кода. В некоторых случаях невозможность доступа к текущему экземпляру объекта представляет проблему правильности.

FxCop

Тогда зачем использовать обычный private метод, когда мы можем разместить поле экземпляра в private static параметрах метода? Разве это не неэффективно?

Просто чтобы представить, что я имею в виду:

public class A
{
    private readonly string _key = "ssss";

    public bool IsGoodKey()
    {
    }

    private static bool ValidateKeyStatic(string key)
    {
        return string.IsNullOrEmpty(key);
    }
    private bool ValidateKey()
    {
        return string.IsNullOrEmpty(_key);
    }
}

И теперь есть два способа реализации IsGoodKey:

    public bool IsGoodKey()
    {
        return ValidateKeyStatic(_key);
    }

И

    public bool IsGoodKey()
    {
        return ValidateKey();
    }

Почему бы не всегда использовать private static?

Answer 1

Если бы производительность была единственной целью static, то, конечно, вы могли бы сделать что угодно static. Но на самом деле ключевое слово не о производительности , а о семантике - то есть член принадлежит классу (и, следовательно, всем экземплярам), или к конкретному c экземпляру вашего класса?

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

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

Answer 2

После того, как вы пометите методы как stati c, компилятор будет отправлять не виртуальные сайты вызовов этим участникам. Создание не виртуальных сайтов вызовов предотвратит проверку во время выполнения для каждого вызова, которая гарантирует, что текущий указатель объекта не равен нулю . Это может привести к ощутимому приросту производительности для чувствительного к производительности кода. В некоторых случаях невозможность доступа к текущему экземпляру объекта представляет проблему правильности.

Возможно, я ошибаюсь, но я думаю, что вы путаете проверку "указатель текущего объекта не равен нулю" и проверка аргумента, передаваемого в метод stati c _key в запросе stati c, ValidateKeyStatic(_key);

Первый относится к указателю, для которого вы вызываете метод. Когда вы записываете следующий вызов метода non-stati c:

foo.Bar(blah)

Автоматическая c проверка ненулевого времени выполнения вставляется для foo, и если это происходит с быть null, вы получите печально известный ReferenceNullException, и ваша программа вылетает. Этой проверки избегают, если метод имеет статус c, следовательно, выигрыш в производительности, потому что метод не вызывается ни для какого конкретного экземпляра объекта.

И это не имеет никакого отношения к тому, с какими проверками вы можете или не можете blah использовать метод Bar.