Jude,

Мне кажется структура понята не совсем верно :) Что значит "взять объект" и "отдать объект"? Мы просто запоминаем указатель (ссылку) на объект, а он остаётся там же где и был... А сам объект - это по большому счёту некий ресурс, который является прослойкой между клиентом и сервером mysql. Какой-нить конфликт может возникнуть при одновременном обращении к ресурсу... Но для каждого экземпляра скрипта (учитывая что php однопоточный по сути), ресурс будет отдельный... Потому конфликты по сути невозможны (а в пределах сервера при одновременном обращении - это уже забота самого сервера и он в этом плане всё делает сам).

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

alex564657498765453,

ну... у меня то вообще ничего из вышесказанного сложностей не вызывает.

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

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

Так что классическая реализация хромает в основном из-за возможности менять соответствующий объект (второстепенно из-за зависимости от наличия класса-синглтона) :)

Как вариант, у mysql соединения например не так уж много разных возможных состояний/параметром (сервер, пользователь, база данных, выполнение транзакции, флаг autocommit). При том выполнение транзакции можно упустить, если прийти к договорённости, что транзакция никогда не будет начата напрямую, а только через изменения соответствующего флага объекта.
Так вот, идеальный случай, это обязательный список аргументов getInstance: host, user, base, autoCommit, которые выставят соответствующие параметры соединения. Но опять же требуется явное соглашение, что нельзя выполнять непосредственно запросы типа "USE db" или "SET AUTOCOMMIT=0".

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



Итак, для нормальной работы и структуры предлагаю в классическую реализацию внести такие изменения:
1. Не статический метод getInstance
2. getInstance получает на вход все данные о состоянии требуемого ресурса. (при том часть из них может иметь некое умолчание, в случае, если аргумент не был передан). Вообще я вижу это в виде уже привычной всем строки типа:
"mysql://user@host:port/db?[nocommit]". В случае если у объекта в копилке нету подходящего ресурса - он создаётся.
3. Объект использующий singleton получает в конструкторе соответствующий объект, и в случае если не получил его - создаёт под себя соединение своими силами или вываливается исключением

При том соблюдается соглашение, что состояние соединения не меняется напрямую в обход соответствующего этому соединению объекта.


В таком виде я понимаю идеальную структуру работы с базой.

ScareCrowавтор Не статический метод getInstance

ты сделал мой день.

А что не так?

Не нравится название? ну пускай будет getResource.