Чем грозит синглтон для БД?

Избавляясь от глобальных переменных, решил ссылаться на PDO объект через промежуточный статический метод.
Сейчас использование БД выглядит так:
# Установка соединения (срабатывает только в первый раз) DB::set('host','db_name','login','pass'); # Получение PDO объекта для взаимодействия DB::get();
В классах работающих с БД для уменьшения связанности создаю приватную статическую переменную которой присваиваю DB::get(). Рассчитываю на то, что в случае если способ получения PDO объекта изменится, мне придется сменить только значение этой самой переменной в каждом классе работающем с БД.
Чем плох такой подход и чем он грозит при разрастании проекта? Имеет ли смысл заводить реестр если таких объектов станет больше двух-трех?

Ответ

Сложно сказать, чем грозит именно в вашем случае. Многие проблемы, связанные со статическими методами и синглтонами для маленьких проектов носят чисто теоретический характер, нежели практический.
Попробуем потеоретизировать.
1. Что будет, если добавится ещё одна база данных?
Придётся добавить некий новый статический класс DB2 и соответствующие методы DB2::set() / DB2::get(). Соответственно, в классах, которые используют оба подключения, придётся добавлять новую статическую переменную.
2. Что будет, если понадобится писать тесты для компонентов, использующих БД?
Придётся полагаться на то, что где-то там внутри компонентов вызов DB::get() сработает правильно. Мы не будем иметь доступа к инстансу соединения с БД, чтобы заменить его каким-нибудь fake-объектом для отдельного тестового случая.
3. Что будет, если добавится несколько других точек входа в код?
Например, помимо основного сайта появятся: API для мобильных приложений, консольные демоны, админская часть, личный кабинет партнёров. В этом случае придётся при инициализации каждого приложения вызывать DB::set() с параметрами подключения. То есть множество приложений окажутся завязанными на один единый синглтон. Вместо этого хотелось бы иметь конфиг подключения, который независимо используется каждым приложением. Ведь гипотетически прослойка для подключения к БД в них может быть разная.

Можно, наверно, придумать ещё много кейсов, в которых всё это станет неудобным и негибким во время роста, но будет ли именно ваша разработка расти таким образом? Вполне возможно, что:
у вас всегда будет одна база данных для бизнеса всегда будет нерентабельным написание тестов точка входа будет всегда одна (не планируется мобильных клиентов и прочих расширений)
В этом случае синглтон является быстрым и простым решением вашей задачи (централизовано хранить подключение к БД).