Преимущества использования частных статических методов

Да, компилятору не нужно передавать неявный указатель this методам static. Даже если вы не используете его в своем методе экземпляра, он все равно передается.

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

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

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

Из Страница правил FxCop по этому поводу:

After you mark the methods as static, the compiler will emit non-virtual call sites to these members. Emitting non-virtual call sites will prevent a check at runtime for each call that ensures that the current object pointer is non-null. This can result in a measurable performance gain for performance-sensitive code. In some cases, the failure to access the current object instance represents a correctness issue.

Когда я пишу класс, большинство методов делятся на две категории:

• Методы, которые используют / изменяют состояние текущего экземпляра.
• Вспомогательные методы, которые не используют / не изменяют текущее состояние объекта, но помогают мне вычислять значения, которые мне нужны в другом месте.

Статические методы полезны, потому что, просто взглянув на его подпись, вы знаете, что при вызове он не использует и не изменяет состояние текущего экземпляра.

Возьмем этот пример:

public class Library
{
    private static Book findBook(List<Book> books, string title)
    {
        // code goes here
    }
}

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

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

Вызов статического метода генерирует инструкцию вызова на промежуточном языке Microsoft (MSIL), тогда как вызов метода экземпляра генерирует инструкцию callvirt, которая также проверяет ссылки на нулевой объект. Однако в большинстве случаев разница в производительности между ними незначительна.

src: MSDN - http://msdn.microsoft.com/en-us/library/79b3xss3(v=vs.110).aspx

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

public class MyClass
{
    private readonly MyDependency _dependency;

    public MyClass(MyDependency dependency)
    {
        _dependency = dependency;
    }

    public int CalculateHardStuff()
    {
        var intermediate = StepOne(_dependency);
        return StepTwo(intermediate);
    }

    private static int StepOne(MyDependency dependency)
    {
        return dependency.GetFirst3Primes().Sum();
    }

    private static int StepTwo(int intermediate)
    {
        return (intermediate + 5)/4;
    }
}

public class MyDependency
{
    public IEnumerable<int> GetFirst3Primes()
    {
        yield return 2;
        yield return 3;
        yield return 5;
    }
}

по каждому методу, обращающемуся к полю экземпляра. Почему это? Поскольку этот процесс вычисления становится более сложным, и в конце класса появляется 15 частных вспомогательных методов, я ДЕЙСТВИТЕЛЬНО хочу иметь возможность вывести их в новый класс, который инкапсулирует подмножество шагов семантически значимым образом.

Когда MyClass получает больше зависимостей, потому что нам нужно вести журнал, а также нужно уведомлять веб-службу (извините за примеры клише), тогда действительно полезно легко увидеть, какие методы имеют какие зависимости.

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

Как уже было сказано, у статических методов есть много преимуществ. Тем не мение; учтите, что они будут жить в куче весь срок жизни приложения. Недавно я потратил день на отслеживание утечки памяти в службе Windows ... утечка была вызвана частными статическими методами внутри класса, который реализовал IDisposable и постоянно вызывался из оператора using. Каждый раз, когда этот класс создавался, память в куче резервировалась для статических методов внутри класса, к сожалению, когда класс был удален, память для статических методов не высвобождалась. Это привело к тому, что объем памяти этой службы потребовал доступную память сервера в течение нескольких дней с предсказуемыми результатами.