Немного теории. Имеется класс для работы с БД (db_class). 
Есть класс example_class, есть класс other_class и есть еще n`ное кол-во классов, которые используют класс для работы с БД. Каким бы способом вы посоветовали организовать связь классов с классом БД?

Варианты с 
муветон, а

не очень хотелось бы использовать. 

Что посоветуете?  

Добавлено через 4 минуты и 10 секунд
Варианты в http://forum.vingrad.ru/topic-188320.html не удовлетворяют требованиям ) Хотелось бы что-то свежее )

Добавлено через 4 минуты и 53 секунды
Завтра приду почитаю ) Заранее всем Огромное спасибище )

Используй Singleton - он же Одиночка. Я так и не понял чем этот вариант тебя не удовлетворяет?

Единственный недостаток - это невозможность передачи параметров __construct`у :(

Как нельзя?

Ты получать объект как будешь?
как минимум DB::getInstance($anyparam)

Вот бери эти $anyparam и передавай в конструктор (при первичной инициализации)

Более того ты их можешь сделать static и работать с ними напрямую DB::$login = 'somelogin';

А необходимую тебе работу по инициализации выполнять или в __construct, или в каком-нибудь DB->init();

Короче способов  - просто масса.
Вот тебе пример одного из вариантов, чтобы было нагляднее.

И еще с ходу один бааальшой косяк. 


Нельзя вынести для использования extends Singleton. Иначе необходимо совершать совершенно нелогичные вещи аля get_class ...

Добавлено через 33 секунды
Fortop, это понятно, но не так элегантно как хотелось бы

Ты определись с функциональностью.

Для того что ты описал Singleton подходит лучше всего. 
Зачем тебе его extends? Не можешь подсказать? Твоя задача этого не требует.
Более того кто тебе мешает расширить его функциональность, объявив

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

Если тебе уж хочется извращений, то посмотри в сторону Factory или Builder. Но ИМХО ты изобретаешь велосипед.
Я подозреваю ты хочешь некий абстрактный Singleton, который будет иметь разные методы в зависимости от типа БД.

Добавлено @ 18:01
А так.. 

напоминает очень странную логику. 
Почему нельзя оторвать голову человеку и носить в сумке, а еще лучше менять и чтобы он был жив попрежнему - накосячили тут....
Ух, неэлегантно!
Чтобы ты знал - это не косяк, это основопологающий прицип работы Singleton - уберешь его и он работать не будет.



Это сообщение отредактировал(а) Fortop - 19.3.2008, 18:03

Я имел в виду что это косяк с точки зрения логики. 



Конкретно в пределах одного класса все гуд. Я тебе плюсик уже поставил. Я хотел использовать Синглетон как паттерн не только для БД, поэтому вынес его и попробовал наследоваться от него. В итоге ничего не вышло так как хотел )

Какой, на, муветон?

Нормальный вариант, только:
1. По правильному передавать объект базы лучше через специальный метод (и хорошо бы, чтобы при повторном вызове кидалось исключение).
2. Если все объекты определенного класса работают с одним набором таблиц из одной базы (а обычно так и есть), лучше не каждому объекту каждый раз указывать базу, а один раз сохранить её в статическом свойстве класса и использовать внутри self::$db

Ничего не понял.
Ты можешь объяснить, что конкретно ты хотел? Возможно Singleton не нужен в твоей ситуации.

Наследуясь от Singleton ты что хотел получить? Какую функциональность?

Вот тебе пример

Fortop, мда. Ушел учить матчасть  __CLASS__ ... 

Да ерунда этот __CLASS__
Для Singleton основным будет являться переопределение getInstance() т.е. ты в любом случае будешь знать какое имя класса у тебя в данной конкретной реализации.
Если же переопределять не будешь - то получишь инстанцию родительского класса.

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