История изменений

синглтон для них них не нужен, константы и без него прекрасно работают

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

Второе преимущество конкретно в PHP - имена класса не требуют global для доступа из функции. Соответственно, не нужно объявлять все конфигурационные переменные, к которым собираешься обращаться.

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

Что касается многопоточности, то в PHP с ней очень легко работать - её просто нет :-) Так что подобные подводные камни синглтонов для PHP в принципе не актуальны. В какой-нибудь Java достаточно навершать synchonized где нужно, либо использовать thread local storage (в зависимости от того, нужно ли шарить состояние синглтона между потоками). В C++ это делать сложнее, но C++ сам по себе сложнее, это норма.

Кстати, ещё есть такой вариант - синглтон может быть совмещён с паттерном стратегия. Например, мы имеем какие-то платформозависимые функции. Пишем абстрактный класс с прототипами этих функций. Пишем реализации под все платформы, наследующие этот класс. В базовом классе делаем метод getInstance, который детектит платформу и создаёт нужного потомка, а затем возвращает (повторные вызовы возвращают сохранённый инстанс, заново тратить время на детект не нужно). В этом случае синглтон может вообще не иметь полей, только методы (но не обязательно). Главная фишка будет в том, что getInstance может вернуть разные реализации, но при этом на детект потратит время только один раз. Конечно, в случае PHP можно просто инклюдить разные файлы в зависимости от платформы (ничто не мешает совместить это с предыдущим методом и перед созданием класса инклюдить его файл в getInstance после детекта). Однако, требование реализовывать платформозависимые методы именно в классе позволяет иметь гарантии, что мы ничего не забыли реализовать (потому что мы унаследуем базовый класс и если забудем переопределить какой-нибудь абстрактный метод, то получим ошибку ещё на этапе создания его экземпляра, а не при обращении к отсутствующей функции, которая может вызываться редко и только при некоторых условиях), а ещё жёстко задать интерфейс.

синглтон для них них не нужен, константы и без него прекрасно работают

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

Второе преимущество конкретно в PHP - имена класса не требуют global для доступа из функции. Соответственно, не нужно объявлять все конфигурационные переменные, к которым собираешься обращаться.

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

Что касается многопоточности, то в PHP с ней очень легко работать - её просто нет :-) Так что подобные подводные камни синглтонов для PHP в принципе не актуальны. В какой-нибудь Java достаточно навершать synchonized где нужно, либо использовать thread local storage (в зависимости от того, нужно ли шарить состояние синглтона между потоками). В C++ это делать сложнее, но C++ сам по себе сложнее, это норма.

Кстати, ещё есть такой вариант - синглтон может быть совмещён с паттерном стратегия. Например, мы имеем какие-то платформозависимые функции. Пишем абстрактный класс с прототипами этих функций. Пишем реализации под все платформы, наследующие этот класс. В базовом классе делаем метод getInstance, который детектит платформу и создаёт нужного потомка, а затем возвращает (повторные вызовы возвращают сохранённый инстанс, заново тратить время на детект не нужно). В этом случае синглтон может вообще не иметь полей, только методы (но не обязательно). Главная фишка будет в том, что getInstance может вернуть разные реализации, но при этом на детект потратит время только один раз. Конечно, в случае PHP можно просто инклюдить разные файлы в зависимости от платформы (ничто не мешает совместить это с предыдущим методом и перед созданием класса инклюдить его файл в getInstance после детекта). Однако, требование реализовывать платформозависимые методы именно в классе позволяет иметь гарантии, что мы ничего не забыли реализовать (потому что мы унаследуем базовый класс и если забудем переопределить какой-нибудь абстрактный метод, то получим ошибку), а ещё жёстко задать интерфейс.

синглтон для них них не нужен, константы и без него прекрасно работают

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

Второе преимущество конкретно в PHP - имена класса не требуют global для доступа из функции. Соответственно, не нужно объявлять все конфигурационные переменные, к которым собираешься обращаться.

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

Что касается многопоточности, то в PHP с ней очень легко работать - её просто нет :-) Так что подобные подводные камни синглтонов для PHP в принципе не актуальны. В какой-нибудь Java достаточно навершать synchonized где нужно, либо использовать thread local storage (в зависимости от того, нужно ли шарить состояние синглтона между потоками). В C++ это делать сложнее, но C++ сам по себе сложнее, это норма.

Кстати, ещё есть такой вариант - синглтон может быть совмещён с паттерном стратегия. Например, мы имеем какие-то платформозависимые функции. Пишем абстрактный класс с прототипами этих функций. Пишем реализации под все платформы, наследующие этот класс. В базовом классе делаем метод getInstance, который детектит платформу и создаёт нужного потомка, а затем возвращает (повторные вызовы возвращают сохранённый инстанс, заново тратить время на детект не нужно). В этом случае синглтон может вообще не иметь полей, только методы (но не обязательно). Главная фишка будет в том, что getInstance может вернуть разные реализации, но при этом на детект потратит время только один раз. Конечно, в случае PHP можно просто инклюдить разные файлы в зависимости от платформы. Однако, требование реализовывать платформозависимые методы именно в классе позволяет иметь гарантии, что мы ничего не забыли реализовать (потому что мы унаследуем базовый класс и если забудем переопределить какой-нибудь абстрактный метод, то получим ошибку), а ещё жёстко задать интерфейс.

синглтон для них них не нужен, константы и без него прекрасно работают

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

Второе преимущество конкретно в PHP - имена класса не требуют global для доступа из функции. Соответственно, не нужно объявлять все конфигурационные переменные, к которым собираешься обращаться.

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

Что касается многопоточности, то в PHP с ней очень легко работать - её просто нет :-) Так что подобные подводные камни синглтонов для PHP в принципе не актуальны. В какой-нибудь Java достаточно навершать synchonized где нужно, либо использовать thread local storage (в зависимости от того, нужно ли шарить состояние синглтона между потоками). В C++ это делать сложнее, но C++ сам по себе сложнее, это норма.

Кстати, ещё есть такой вариант - синглтон может быть совмещён с паттерном стратегия. Например, мы имеем какие-то платформозависимые функции. Пишем абстрактный класс с прототипами этих функций. Пишем реализации под все платформы, наследующие этот класс. В базовом классе делаем метод getInstance, который детектит платформу и создаёт нужного потомка, а затем возвращает (повторные вызовы возвращают сохранённый инстанс, заново тратить время на детект не нужно). В этом случае синглтон может вообще не иметь полей, только методы (но не обязательно). Главная фишка будет в том, что getInstance может вернуть разные реализации, но при этом на детект надо тратить время только один раз.