Почему синглтон настолько плох в среде PHP? [дубликат]

На этот вопрос уже есть ответы здесь :

Закрыт 8 лет назад .

Возможный дубликат:
Кому нужны синглтоны?

Мне было интересно , каковы недостатки использования синглтонов в скриптах php. Я их много использую и иногда не понимаю критики разработчиков. Некоторые примеры:

У меня есть класс запроса:

Очистка входных данных POST, GET, COOKIE и использование их вместо глобальных массивов - строго и глобально. Like

$request = Request::getInstance();
$firstname = $request->post('firstname', $additionalFilters);

Всегда есть только ОДИН запрос на запрос. Почему использование синглтона в этом случае - плохая идея?

То же самое для $ _SESSION:

У меня есть класс Session (Singleton), который представляет массив $ _SESSION, потому что существует только один сеанс, и я использую его глобально.

База данных

$mysql  = DB::getInstance('mysql', 'dbname'); //pseudo
$sqlite = DB::getInstance('sqlite', 'dbname'); //pseudo

Для каждого типа базы данных мне нужен только ОДИН объект и никогда БОЛЬШЕ. На мой взгляд, в противном случае существует опасность хаоса.

Уникальные строки

Также я часто использую классы для представления / использования уникальной строки таблицы db.

$article = Article::getInstance($id);
$navigation = Navigation::getInstance($id);

Я вижу только преимущества в этом. Мне никогда не нужен второй объект, представляющий уникальную строку. Почему синглтон - такая плохая идея?

Фактически, большинство (почти все) моих классов не имеют общедоступного конструктора, но всегда имеют статический метод, такой как getInstance ($ id) или create (), поэтому класс сам обрабатывает возможные экземпляры (что не означает, что все они по определению являются одиночными)

Итак, мой вопрос: есть ли какие-то недостатки, которые я еще не осознавал. И о каком конкретном сценарии думают сомневающиеся-одиночки, когда советуют не синглтоны.

Изменить:

Теперь у вас есть синглтон, который обертывает $ _POST, но что, если вы нет $ _POST, но вместо этого вы хотите использовать файл для ввода? В этом случае было бы удобнее, если бы у вас был абстрактный класс ввода, и создать экземпляр POSTInput для управления вводом через опубликованные данные.

Хорошо, допустимые преимущества. Я этого не понимал. Особенно, что касается класса Request.

Я все еще сомневаюсь, подходит ли такой подход. Предположим, у меня есть класс «Функциональность», который выполняет конкретный запрос (например, компонент гостевой книги). Внутри этого класса я хочу получить отправленный параметр. Итак, я получаю свой одноэлементный экземпляр Request

$req = Request::getInstance(); 
$message = $req->post('message');

. Таким образом, только мой функциональный объект заботится о классе Request.

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

Конечно, я могу определить необязательный параметр при создании функциональности. Но в какой-то момент это приводит к полному излишку параметра. Или нет?

задан Community 23 May 2017 в 12:00

0 ответов

Другие вопросы по тегам:

php design-patterns singleton

Почему синглтон настолько плох в среде PHP? [дубликат]

0 ответов

Похожие вопросы: