Статика VS Singleton?

Question

[azverin]

Есть ли какой-то профит в использовании объекта Singleton вместо статических атрибутов и методов?

Singleton:

class One {
    private $var;
    private $instance;

    /** Пропущена защита конструкторов, клонов и wakeup`ов. */

    static public function Instance () {
        if ( is_null( $this->instance ))
            $this->instance = new static;

        return $this->instance;
    }

    public function set ( $var ) {
        $this->var = $var;
    }

    public function get () {
        return $this->var;
    }
}
One::Instance()->set(2);
echo One::Instance()->get();

Статика:

class Two {
    static private $var;

    static public function Set ( $var ) {
        self::$var = $var;
    }

    static public function Get () {
        return self::$var;
    }
}
Two::Set(2);
echo Two::Get();

Я везде использую вариант «Two», но вдруг я что-то важное упускаю?

Answer 1

[gro]

Основное преимущество объектов, полизморфизм, на:
function func($obj) {
$obj->method1();
$obj->medhod2();
}
Получили какой-то объект и работаем с ним через определённый интерфейс не задумываясь о его реализации. Если вызывающему коду нужно будет подсунуть нам другую реализацию, нас это не волнует.

И откуда получен этот объект, через Singleton или нет, много подобных объектов в системе или он один, нам не интересно.
А со вторым способом мы жестко привязались к классу.

Comments

[Анатолий]

Это можно решить так же наследованием статики

[gro]

Ага, и передавать имя класса :)

[Анатолий]

Для наслевавания не нужно имя класса, пользуйся всегда родительским и все, любой другой наследник будет иметь его интерфейс. Ваш К.О.

[gro]

Как мне в конкретном месте вызвать статический метод класса, не имя ссылки на этот класс и пользуясь только родительским?

[Анатолий]

А как Вам вызвать уникальный метод обьекта, используя интерфейс родителя? Смысл тогда в интерфейсе, если Вы хотите вызвать метод которого в нем нет?

[gro]

Используя интерфейс родителя, я вызову переопределённую реализацию метода (для объектов). Имея же только имя базового класса я смогу вызвать только базовую реализацию статического метода.

Answer 2

[Melkij]

Если вам нужна кучка функций, хоть и под общей эгидой — статика.
Если вам нужен объект — одиночка.

Важная между ними разница — вызов конструктора и деструктора. У синглтона и тот и другой вызываются автоматически.
Тогда как в куче статических методов вам придётся в каждом методе проверять, был ли вызван конструктор для достижения того же эффекта. Да, от этого можно избавиться, реализовав __CallStatic и приняв правила именования методов так, чтобы в чистом виде они никогда не вызывались, но не кажется ли это вам костылём?

Comments

[azverin]

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

С другой стороны я их почти не использую, т.к. максимально стараюсь задействовать lazy-инициализацию всего что можно, и до выполнения непосредственно действия часто ничего не происходит.
А логика инициализации всё равно вынесена отдельно и проверяет своё состояние перед каждым вызовом.

Если вам нужен объект — одиночка.

Не очень осознаю смысловое понятие «объект» в данном ракурсе. Скажем регистр — это объект?
Или подключение к БД, которое почти всегда нужно в единственном количестве? Формально да, объект: состояние, данные и методы.
При этом таскаться они будут повсеместно и DB::Query('...') по мне симпатишнее чем DB::Instance()->query('...');

[Melkij]

Формально, я не достиг дао ООП и под объектом в контексте синглтона понимаю именно конструктор и деструктор.
Говоря конкретно о PHP, статичные классы, в отличии от синглтона, не умеют __get, __set, обращение к необъявленным членам приводит вовсе к fatal error, что может накладывать определённые неудобства, если захочется динамично обращаться к членам.

[Stdit]

Самый верный ответ. Даже если у объекта нет никакой инициализации сейчас, никто не гарантирует что она не понадобится никогда и никому потом. А магия с __callStatic здесь это зло, призванное заменить нормальный конструктор.

Answer 3

[Анатолий]

Не смотря на камент выше, разницы никакой абсолютно (вызов разный). В итоге и там и там появляется лишь один экземпляр сущности с которой Вы работаете, ну и + синглтон в памяти будет занимать еще лишние несколько килобайт как обьект. Главное что работу они выполняют одинаково.

Comments

[Анатолий]

Кстати, статика не может вот так:
Singlton::getInstance()->add('qwe')->add('asd')->save();

[gaelpa]

«килобайт»?

[azverin]

Ну если говорить о регистре к примеру, то вызвав Registry::DB() логично получить объект с которым можно работать в цепочках.

Разница собственно Registry::Instance()->DB()->… или Registry::DB()->…

[Kirill Boldyrev]

В случае динамики вы можете подменить реализацию самомго Registry. А в случае статики — не сможете. Например при тестировании очень может помочь.

[Аркадий]

Singlton::getInstance()->add('qwe')->add('asd')->save();

Для синглтона это тоже странно, ведь объект не уникален.

Answer 4

[jrip]

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

Answer 5

[Ogra]

А я вот наоборот, думаю, как бы избавиться от Синглтонов и Статических объектов. Есть мнение, что это — зло, потому что равносильно глобальным данным.
P.S. Просто попался проект, на котором большими красными буквами написано Оверинжиниринг, и там очень много используется Синглтонов — по делу и не по делу.

Comments

[Анатолий]

Скажите хоть один нормальный аргумент против 5-ти глобальных переменных (не думаю что в проекте много синглтонов). Учитывая что это (допустим возьмем статику) названия переменных которые нигде ничего _никогда_ не перекрывают (Вы ведь не назовете переменную как название класса?).

[Ogra]

В этом проекте 10 (десять!) синглтонов. И еще несколько статических классов. Я обычно не против двух глобальных переменных — $user, $db. Все иное, на мой взгляд, перебор.

[Павло Пономаренко]

обычно не против двух глобальных переменных — $user, $db.

Я ещё могу предположить на счёт db. Но юзера то за что?

[jrip]

$user это, наверное, имеются ввиду данные об авторизации.

[Владимир Чернышев]

TheShock, в контексте обычного использования PHP юзер обычно глобален для приложения, поскольку идеология CGI «один запрос — один процесс» остаётся, пускай и несколько замаскированная в случае модулей серверов или FastCGI. Скорее баз данных может быть несколько, чем юзеров.

Answer 6

[etc]

Тоже столкнулся с этим вопросом, когда реализовывал реестр. Пока остановился на статическом массиве и методах, ибо там всего 2 метода и 1 статический массив.

Answer 7

[Владимир Чернышев]

Смотря как использовать. Даже если забыть про конструктуры/деструкторы и прочий «сахар», то у синглтона есть и другое преимущества — его можно передать в качестве параметра функции/метода, то есть уменьшить связанность кода.