Каким образом конфигурировать инициализацию Singleton-а?

Question

[Сергей]

Есть библиотека, в которой имеет место быть класс, у которого в рамках одного процесса позволительно существование только одного инстанса, т.е. фактически это Singleton. Беда в том, что инициализация этого самого инстанса имеет несколько динамических параметров, которые надо каким-то образом передавать.


Решение должно работать на PHP > 5.2. Единственное, что мне пришло на ум:

public static function init($params) {
		if(self::$instance) {
			throw new Exception(__CLASS__ . ' already initialized');
		}
		$class = __CLASS__;
		self::$instance = new $class($params);
	}

	public static function getInstance() {
		if(!self::$instance) {
			throw new Exception(__CLASS__ . ' is not initialized');
		}
		return self::$instance;
	}

Но оно кажется далеко не самым удачным. У кого-нибудь есть ещё какие идеи, паделитесь?

Спасибо!

Comments

[lair]

А что значит «несколько динамических параметров»? Зачем синглтону параметры? От чего они зависят?

Answer 1

[LastDragon]

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

Comments

[Сергей]

Ок, а как тогда гарантировать уникальность объекта??

[LastDragon]

Это «зависит от архитектуры вашего приложения». Например, никто не мешает запретить изменять объект в registry после того как он был помещен туда при инициализации приложения. А насчет уникальности — борьба с ветряными мельницами (всегда можно создать второй, получится немного сложнее разве что).

[LastDragon]

А, ну и очевидный вариант — обычный singleton (без параметров), все необходимые параметры класс может получить самостоятельно.

[Сергей]

Блин, ну это уже в какой-то холивар переходит… Какой смысл запрещать изменять объект, если программист всегда сможет создать ещё один? Что плохого в том, чтобы явным образом ограничить программиста в инициализации более чем одного инстанса класса, если это действительно необходимо? Если программист будет использовать костыль типа unesrialize(serialize($instance)) чтобы обойти эту унификацию, то значит берёт на себя ответственность за все возможные последствия.

[Сергей]

А самостоятельно это как например, через глобальные константы/переменные?

[LastDragon]

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

[Сергей]

В том то и дело, что никакого такого SingletonConfiguration класса для хранения динамических параметров инициализации нет и быть не может т.к. мы не можем гарантировать существования инстанса этого класса на момент вызова Singleton::getInstance

Answer 2

[Gron]

en.wikipedia.org/wiki/Multiton_pattern
en.wikipedia.org/wiki/Immutable_object

Извиняюсь конечно но если нужны именно одиночки — юзайте Multition (онже пул одиночек), если хотите чтоб менялось состояние объекта который вы создали 1 раз — юзайте неизменяемый (Immutable)

Comments

[Сергей]

Даже не представлю как будет выглядеть реализация Immutable на PHP..( А Multiton очень похож на тот код, что я привёл в примере, только у них __construct вместо ::init() и getInstance() параметризован какого-то хрена)

Answer 3

[Сергей]

Копия этого вопроса на StackOverflow: stackoverflow.com/questions/11081324/singleton-initialization-configuration

Answer 4

[gaelpa]

Если класс — синглтон, то и параметры его глобальны в рамках приложения или сеанса.
1. Может пусть он сам выясняет свою конфигурацию из внешнего источника?
2. Сделать метод/класс-обертку, собирающую (сама) параметры и передающую их в конструктор не-синглтона, после чего возвращающую тот же инстанс. Обертка на уровне приложения, так что инкапсуляция не страдает.

Comments

[Сергей]

Из какого внешнего источника, откуда будут параметры инициализации собираться? См. комменты к habrahabr.ru/qa/20650/#answer_84107

[gaelpa]

Если таковой есть и доступен, например, в рамках фреймворка.
Если нет, см. п.2: не-синглтон + обертка для доступа.

[Сергей]

Нет никакого фреймворка т.к. либа standalone. И «обёртка плюс доступ» не подходят т.к. не гарантируют уникальность.

[gaelpa]

Тогда, специально для таких извернутых условий:

/* in lib */
abstract class single{ 
  abstract public static function Singleton(); 
  protected function __construct($params){}
}

/* in app */
class  mySingle extends single {
  public static function Singleton(){
     return static::$instance?:static::$instance=new static(collectArguments());
  }
}

Уникальность гарантируется тем, что без обертки вы этот объект не получите никак.

[Сергей]

Вполне рабочее решение, разве что не очень удобно в плане реализации, и не будет работать на PHP 5.2 :(

[gaelpa]

До синтаксиса 5.2 вполне можно опуститься. Но в реальных условиях я бы все-равно предпочел бы синглтон-обертку (классом или методом/функцией — см в SO) над не-синглтон объектом.
Или вы недоговариваете о каких-то дополнительных соображениях по требованиям, ограничивающих такой подход.

Answer 5

[Николай Васильчук]

Тут есть пример синглтона на PHP

    public static function singleton()
    {
        if (!isset(self::$instance)) {
            echo 'Создание нового экземпляра.';
            $className = __CLASS__;
            self::$instance = new $className;
        }
        return self::$instance;
    }

Мне кажется очевидным сделать как-то так

    public static function singleton($params)

Собственно и получится примерно то, что вы и описали.
Мне кажется, это нормально.

Comments

[Николай Васильчук]

В википедии примеры как-то получше )

[Николай Васильчук]

Хотя, это неправильный какой-то стнглтон получается, если он инициализируется с параметрами. Приведите пример использования, чтоли.

[Сергей]

Не самое удачное решение. Юзер напишет

class::singleton($params1);
class::singleton($params2);

и в последнем случае не узнает о том, что его $params2 никак не повлияют на результат. Т.е. тут вы скрещиваете понятие синглотона и фабрики, что само по себе очень противоречиво.

[Николай Васильчук]

В последнем случае (если взять пример автора) он схватит Exception.

[Сергей]

Таки это будет ниразу не очевидно для программиста. А что если он напишет этот код в конструкции типа

if(!mt_rand(0, 1000)) {
class::singleton($params2);
}

То маловероятно, что эта ошибка будет отловлена им в процессе разработки и даже тестирования.

[Николай Васильчук]

Приведите пример, зачем вам синглтон, который инициализируется с параметрами?

[Сергей]

Зачем? Тогда начётся холивар на тему насколько мне актуальна его уникальность :) Мне нужно хоть какое-то решение в рамках озвученной задачи, пусть даже такое плохое как stackoverflow.com/a/11081838/341260

[Николай Васильчук]

Ну тогда делайте не Exception, а trigger_error, чтобы не вводить разработчика в заблуждение.

Answer 6

[CrazySquirrel]

<?
class MySingleton
{

        static private $_instance;

        private function __construct($params)
        {
                //При необходимости, недостающие параметры обработать тут.
                $this->_params = $params;
        }

        public static function getInstance()
        {
                if (!self::$_instance instanceof self) {
                        self::$_instance = new self(func_get_args());
                }

                return self::$_instance;
        }

        ...

}


MySingleton::getInstance('param1', 'param2', 'paramN')->doSomething();

А вообще это не кошерно.

Юзайте Registry.

Comments

[Сергей]

1. Ваше решение введёт в заблуждение программиста, если он повторно вызовет getInstance с другими параметрами
2. Registry не гарантирует уникальность инстанса класса.

[CrazySquirrel]

Стрёмных решений можно придумать много, суть то в том, что так делать не стоит.

Answer 7

[Анатолий]

Разделите конструктор и параметры:

class Singleton{
    static public punction getInstance(){ ... }
    public function applyParams($params){ ... }
}

$singleton = Singleton::getInstance()->applyParams($param1);
// some code
// change param
$singleton->applyParams($param2);

Comments

[Сергей]

Хорошее решение, если бы не одно но: параметры инициализации актуальны на стадии инициализации объекта, не раньше и не позже.

[Анатолий]

Ну тогда это уже не синглтон, если две версии его могут отличаться =) Вам нужна фабрика.

[Сергей]

Фабрика не гарантирует уникальность :) В этом вся загвоздка, потому и опубликовал вопрос, что случай не простой.

[Анатолий]

Дык и синглтон с вашими условиями не гарантирует уникальности при таких действиях, единственный вариант делать как вы — в лоб! Есть екземпляр? Хочешь второй? Ошибка.

Answer 8

[AxisPod]

Я бы использовал статический метод для инициализации. И который кидал бы исключение в случае, если экземпляр уже создан.
Singleton::init(.....);
Singleton::getInstance()…
Singleton::init(....); // throw exception…

Comments

[Сергей]

Ну т.е. тот же вариант, что я в описании вопроса привёл? У него есть один большой минус: спецификация класса не подразумевает обязательность вызова init перед вызовом getInstance(