Статические классы в C#

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

Что вы имеете в виду под «опасностью»?

Не уверен в C#, но в C++ статический объект будет инициализирован при инициализации, и у вас нет прямого контроля над этим (особенно в многопоточных приложениях). Итак, вам нужна функция для вызова вашего объекта, а не просто для его прямого вызова (если вам не нужен непереносимый код)

Единственное, что мне сразу кажется очевидным, это то, что статический класс - это в основном просто набор функций с ограниченной областью видимости (явно избегая здесь «методов»), а синглтон - это то, что вы можете создать, даже если вы можете иметь только 1. 1> 0.

Вы можете передать синглтон в качестве аргумента чему-то, что ожидает объект определенного интерфейса, вы не можете передать статический класс в любом месте (кроме как с помощью некоторых уловок с отражением)

Как заметил Роберт Гулд, вы теряете контроль над строительством. Вы также столкнетесь со строительными проблемами, которые намного более неясны. Статические классы быстро заканчиваются блоками статического инициализатора. Эти блоки вызываются при первом обращении к вашему типу, и этот порядок может быть не так хорошо определен, как вы думаете. Таким образом, порядок выполнения этих статических инициализаторов может измениться без вашего планирования и вызвать странные ошибки.

Как сказал Роберт ранее, инициализация - главный недостаток статического класса. Статический класс обычно инициализируется лениво, в последний возможный момент. Однако вы теряете контроль над точным поведением, а статические конструкторы работают медленно.

Часто статические классы используются для хранения глобальных данных. А глобальные данные создают неявную зависимость между другими вашими объектами / классами. Поэтому вы должны проявлять осторожность при изменении этого «глобального объекта». Может сломать ваше приложение.

Во многих отношениях статический класс и синглтон похожи. Одно большое отличие состоит в том, что синглтон может реализовывать некоторые интерфейсы, что невозможно со статическим классом. Например, Comparer<T>.Default / EqualityComparer<T>.Default предоставляют (через интерфейс) возможность использовать элемент при сортировке / использовании словаря.

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

В контексте реализации singleton, я думаю, опасности нет. Я часто делаю то же самое, реализуя синглетон через статический класс. Логически ссылка на объект не нужна, если она единственная и уникальная.

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