Когда использовать статические классы и методы?

Я думаю, что следующие две ссылки дают четкий ответ на то, что вы ищете. Взгляните на них:

Для статических классов:

Когда использовать статические классы в C#

Для статических методов:

Когда уместно использовать статические методы? ( Джон Скит [Гуру] ответил на этот вопрос: o))

Одна вещь, о которой следует помнить, — это последствия тестирования статических методов. Статический метод "запечатывает" множество швов. Швы — это то место, где вы можете изменить поведение, не меняя производственный код; примерами являются подклассы или ссылки на библиотеку тестирования. Поскольку статические методы разрешаются во время компиляции и не связаны динамически, вы не можете добавить тестовый объект и изменить поведение статического метода. Тестирование этого класса будет утомительным.

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

Вот хорошая ссылка из блога тестирования Google:Статические методы — это смерть для тестируемости

Я думаю, что общим правилом может быть то, что служебные функции должны быть статичными. Типичным примером может быть то, что в любом языке oop класс Math будет содержать статические методы, такие как sqrt(), поскольку на самом деле нет необходимости иметь что-то вроде отдельного объекта Math.

Что касается статических классов, вы должны думать о классах, сохраняющих форму состояния, обычно такую ​​как информация о сеансе, которая необходима независимо от точного пути, пройденного через ваше приложение, и из которых вам обычно нужен ровно один. (подумайте о своем браузере, который, вероятно, всегда хранит ровно 1 класс cookie-jar)

Статические переменные — это менее опасный близнец глобальных переменных (они сохраняют свое значение, но их область действия ограничена функцией), которые обычно полезны либо для хранения некоторой формы состояния (например, для кэширования данных), либо для перечисления вещей, которые должны быть уникальный, но чья нумерация не очень важна за пределами вашей функции или приложения (скажем, нумерация отладки или профилирования кричит из ваших собственных функций debug("..") или profile())

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

Как я понимаю, это когда нет смысла создавать объект класса для вызова действия или этот класс является общим в приложении. Например, в C# класс Console запечатан (поэтому вы не можете создать объект и наследовать его, да и смысла в этом нет). Однако профессионалы объяснят вам лучше.