У меня есть общий вопрос..., когда я должен использовать статические классы или статические методы?.. Я знаю идею, что статические методы можно назвать, не инстанцируя..., и статические классы должны только использоваться для статических методов?..., но есть ли какие-либо проблемы производительности также с ним... и когда они должны быть предпочтены по методам экземпляра и классам?.. Если кто-то мог бы лишь кратко упомянуть, когда я должен выбрать использование их и когда я должен избежать их?
Я думаю, что следующие две ссылки дают четкий ответ на то, что вы ищете. Посмотрите их:
Для статических классов:
Когда использовать статические классы в C#
Для статических методов:
Когда уместно использовать статические методы? (Jon Skeet (Гуру) ответил на этот вопрос :о) )
Тут предыдущая запись кажется: Когда использовать статические классы в C#
Я бы подумал, что статические классы нужны для хранения функций или данных, которые вы хотите вызвать без необходимости создавать для них объект. Если я помню, инстанцирование объекта помещает его в память. И, следовательно, статический класс, не являющийся объектом, не помещается в память? Давненько я не ходил на теоретические занятия ;( Извините.
Одна вещь, о которой следует помнить, - это последствия тестирования статических методов. Статический метод «запечатывает» множество швов . Швы - это то место, где вы можете изменить поведение, не меняя производственный код; примеры являются подклассами или ссылками на библиотеку тестирования. Поскольку статические методы разрешаются во время компиляции и не связаны динамически, вы не можете добавить объект тестирования и изменить поведение статического метода. Тестирование этого класса будет затруднением.
Для таких вещей, как математические функции, вы можете быть уверены, что статический метод подойдет, но вам почти наверняка не нужен статический метод, который подключается к базе данных. Подумайте, как бы вы тестировали код, использующий статический метод, который вы собираетесь создать .
Вот хорошая ссылка из блога о тестировании Google: Статические методы - смерть для тестируемости
Я думаю, что общее практическое правило может заключаться в том, что служебные функции должны быть статическими. Типичным примером может служить то, как на любом языке oop класс Math будет содержать статические методы, такие как sqrt (), поскольку на самом деле нет необходимости иметь что-то вроде отдельного объекта Math.
Что касается статических классов, вам следует подумать о классах, сохраняющих форму состояния, обычно такую как информация о сеансе, которая необходима независимо от точного пути, пройденного через ваше приложение, и из которых вам обычно нужен ровно один. (подумайте о своем браузере, который, вероятно, всегда хранит ровно 1 класс типа cookie-jar)
Статические переменные - менее злые двойники глобальных переменных (они сохраняют свое значение, но их область действия ограничена функцией), которые обычно полезны либо для сохранения некоторой формы состояния (например, кэширование данных), либо для перечисления вещей, которые должны быть уникальными, но чья нумерация не очень важна за пределами области вашей функции или приложения (скажем, нумерация отладки или профилирование криков из вашей собственной отладки (" .. ") или profile () функции)
В принципе, используйте любую из них только тогда, когда вы очень уверены, что выполнение действий" правильным "способом, подобным ООП, приведет к созданию монстра.
Насколько я понимаю, это когда нет смысла создавать объект класса для вызова действия или этот класс является обычным в приложении. Например, в C # класс консоли является запечатанным (поэтому вы не можете создать объект и наследовать его, да и вообще нет смысла это делать). Однако профессионалы объяснят вам лучше.