Статические или частные

Question

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

Статическая переменная:

Public Function Whatever() as Boolean 
    Static Flag as Boolean 
    If not Flag then 
     ' do something 
     Flag = True 
    end if 
    Return Something 
End sub 

VS:

Private Variable:

Private Flag as Boolean 
Public Function Whatever() as Boolean 
    If not Flag then 
     ' do something 
     Flag = True 
    end if 
    Return Something 
End sub 

Если кто не знает, в противном случае, выше функционально эквивалентны, кроме того, что "Приват" Флаг используется для использования в других местах класса.

Вопросы начинают возникать с Статикой .. как ..

Где они хранятся .. когда они действительно созданы и расположены и т.д.

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

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

Есть ли НАСТОЯЩАЯ причина, когда-либо использующая статику?

PS: Надеюсь, это проходит тест вопрос так ...

Примечание Я не спрашиваю особенности о том, как создаются статика .. Я еще спросить, что если что-нибудь сделает с использованием статического стоит.

ADDENDUM ....

я сделал немного больше исследований, и нашел, что это довольно поучительно.

https://weblogs.asp.net/psteele/7717

Answer 1

Так из исследований я пришел со следующим.

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

Как Конрад предполагает, что основной причиной использования статики является минимизация области действия переменной там, где она необходима.

Так ... когда требуется

1. Используйте простые статические переменные (булевы, целочисленные и т.д.) в функции и подпрограммы, которые используются реже. Если вы ожидаете, что пользователи этого класса ВСЕГДА вызовут эту функцию и ожидают, что будет 1000 экземпляров класса ... вы добавляете много накладных расходов.

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

3. Аналогичным образом не используйте статические переменные в качестве ссылки на какой-либо другой объект в вашем проекте. Это может помешать указанному объекту быть мусором, собранным в другом месте вашего кода, поскольку он по-прежнему ссылается.

4. И, наконец, если вы используете метод Private variable, дайте ему имя, которое делает очевидным, что эта переменная используется для этой функции. stat_Half_Time_Score

Answer 2

Есть ли на самом деле SOLID причина когда-либо использовать статику?

Да. Это, возможно, в первом письме от SOLID: S за «принцип единой ответственности». В данном контексте это немного другое правило:

Objects should have the smallest possible scope.

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

Следовательно, в вашем случае лучшая идея действительно сделала бы переменную переменной-static (= local), а не объектно-частной переменной.

Это действительно необычно в моем опыте. Но это лучшая практика.

(С точки зрения производительности/памяти эти два варианта были бы точно идентичны.)