Singleton PHP - обработчик баз данных

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

Я, например, не думаю, что это такая уж плохая идея, и считаю, что синглтон вполне подходит для обработчика базы данных. Это просто, интуитивно понятно, и у вас больше контроля над экземпляром Singleton, чем над глобальной переменной.

Я использую обработчик одноэлементной базы данных для большинства своих небольших веб-приложений. В сочетании с внешним файлом конфигурации и PDO в качестве метода доступа к базе данных он по-прежнему может быть очень гибким при переходе от проекта к проекту, если методы не зависят от модели приложения (например, getRow или getAll вместо getThing или getBreakfast) . Я просто стараюсь убедиться, что все мои константы доступа определены отдельно.

Многие проблемы синглтонов связаны, в основном, с более сложными языками, чем PHP.

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

В PHP есть глобальные переменные. Глобальные переменные PHP обычно являются плохой практикой, но они существуют, если вам нужно их использовать.

Однако, есть несколько причин, по которым вы захотите использовать синглтон в PHP.

Синглтоны полезны, когда вызов getInstance (каноническое название метода, возвращающего единственный экземпляр синглтона) может быть сделан в любой точке скрипта. До этого момента объект не должен существовать. Если бы объект был глобальной переменной, то либо он уже должен был бы существовать, либо код, пытающийся сослаться на объект, должен был бы сначала его инстанцировать. Фактически, везде, где он может быть использован, он должен быть правильно инстанцирован. Централизовав создание единственного объекта в getInstance, вы избежите необходимости создавать copy-and-paste boilerplate каждый раз, когда вам нужно сослаться на объект.

Объекты баз данных обычно создаются очень рано во время выполнения запроса, поэтому специфическое преимущество Singleton-ness будет упущено.

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

Другой альтернативой является шаблон реестра, который фактически является контейнером для вещей, которые в противном случае были бы глобальными. Если вам не нравятся глобальные переменные, но вы не возражаете против того, чтобы они были эффективно разделены по именам, это решение может вам понравиться.

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

В паттерне Singleton нет ничего плохого, я постоянно его использую.

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

Я думаю, что некоторым разработчикам он не нравится из-за зависимостей, которые могут быть созданы с помощью этого метода. Почитайте о Dependency Injection, по-моему, там описывается, почему синглтоны плохи, но я точно не помню.

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

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