Singleton factory для управления и упаковки нескольких объектов базы данных

Question

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

Было бы очень удобно, если бы я мог сделать все это в одном классе. Я пробовал использовать одноэлементный завод (в то время это казалось хорошей идеей), только чтобы понять, что, похоже, нужно возвращать другие классы, чтобы быть полезными. Есть ли простой способ объединить функциональные возможности фабрики singleton и базы данных, или я должен просто поместить функции переноса базы данных в другой класс?

static private $instance = array(); 

private function __construct($name) { 
    switch ($name) { 
     //select db connection 
    } 

    $this->db = $this->getDb(); 
    return; 
} 

protected function __clone() { 

} 

public static function singleton($name) { 
    if (!isset(self::$instance[$name])) { 
     $c = __CLASS__; 
     self::$instance[$name] = new $c($name); 
    } 
    return self::$instance[$name]; 
} 

public function wrapperFunction() { 
    //stuff 
} 

Answer 1

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

Однако, в интересах уменьшения number of WTFs per minute, я пойду с предложением GoalBased о разделении вещей на два класса.

Answer 2

Я делаю что-то подобное довольно часто (например, для управления несколькими подключениями по базе данных по имени). Единственное изменение, которое я предложу, - это сделать конструктор и массив $instance защищенным. Причина в том, что FAR легче тестировать таким образом (поскольку вы можете расширить его с помощью класса-оболочки, чтобы иметь возможность доступа к ним и создавать и уничтожать экземпляры по мере необходимости). Конечно, это открывает возможность для кого-то сделать это в приложении, но зачем выбрасывать возможность управления экземплярами из дочернего класса?

Только мой $ 0,02 ...