ООП I холивар на тему Синглтонов

902
.
╭∩╮ (`-`) ╭∩╮
L!MP (24.12.2011/21:39)
Это когда?
Вот тут:
AlkatraZ, Да я в курсе всех минусов синглтонов
Использовал их (именно в прошедшем времени)
.
AlkatraZ, Так не пойдёт, давай тогда как-нибудь конкретизируем: ты высказуешь минус данного шаблона - мы пытаемся его оспорить или по крайней мере минимизировать .
.
AlkatraZ
╭∩╮ (`-`) ╭∩╮
L!MP (24.12.2011/21:46)
AlkatraZ, Так не пойдёт, давай тогда как-нибудь конкретизируем: ты высказуешь минус данного шаблона - мы пытаемся его оспорить или по крайней мере минимизировать .
Минус я высказал в 1-м посту.
А именно, я почти не видел примеров из реальной жизни, когда синглтон действительно нужен и задачу нельзя решить другими, причем более эффективными методами.
---
Там же я дал условие, ты приводишь пример, где синглтон действительно нужен.
Нет примера - мне +
Есть пример, но я смогу доказать, что применение синглтона неоправдано - мне +
Сможешь доказать, что синглтон в конкретном случае нужен - тебе +
.
AlkatraZ
╭∩╮ (`-`) ╭∩╮
Если так и не будет примеров и партия будет выйграна "всухую", то последует логический вывод:
синглтон - зло! Не применяйте его.
Причем этот вывод я уже читал, причем много раз на весьма серьезных англоязычных программерских тусовках: Singletone are evil
Наберите в Гугле этот запрос, прочитаете много интересного
.
AlkatraZ (24.12.2011/21:52)
А именно, я почти не видел примеров из реальной жизни, когда синглтон действительно нужен и задачу нельзя решить другими, причем более эффективными методами.
Почти любую задачу можно решить нескольками методами и оценка их эффективности может быть понятием субьективным.
Кпримеру, запрос к приложению (или ответ от приложения).
Он может быть только один в рамках сценария.
.
╭∩╮ (`-`) ╭∩╮
L!MP (24.12.2011/22:02)
Почти любую задачу можно решить нескольками методами и оценка их эффективности может быть понятием субьективным.
Кпримеру, запрос к приложению (или ответ от приложения).
Он может быть только один в
Приведу простой пример.
Одной из вроде бы очевидных целей для синглтона - это Registry
Вот, глянь как реализован Registry в mobiCMS (даю урезанную версию, но суть видна).
/**
 * @package    mobiCMS
 * @copyright  Copyright (C) 2007-2012 mobiCMS team
 * @license    LICENSE.txt (own license, see attached file)
 * @version    VERSION.txt (see attached file)
 * @link       http://mobicms.org
 */

class Registry extends ArrayObject
{
    private static $_registry = null;

    public function __construct($array = array(), $flags = parent::ARRAY_AS_PROPS)
    {
        parent::__construct($array, $flags);
    }

    public static function getInstance()
    {
        if (self::$_registry === null) {
            self::$_registry = new Registry;
        }
        return self::$_registry;
    }

    public static function get($index)
    {
        $instance = self::getInstance();
        if (!$instance->offsetExists($index)) {
            throw new RuntimeException("No entry is registered for key '$index'");
        }
        return $instance->offsetGet($index);
    }

    public static function set($index, $value)
    {
        $instance = self::getInstance();
        $instance->offsetSet($index, $value);
    }

    public function offsetExists($index)
    {
        return array_key_exists($index, $this);
    }
}


Там может с первого взгляда показаться, что это синглтон, ведь есть статический метод getInstance() но это не синглтон, ты можешь спокойно создать экземпляр класса.
getInstance() нужен, чтоб не передавать реестр в виде параметра в классы, а можно было бы вызвать Registry::
.
Или даже так (пример из реальной жизни, считай это было вчера):
Есть у меня ServiceLocator, именно этот шаблон я решил использовать для управления зависимостями в своем коде.
Но сам локатор я сделал через синглтон и считаю это единственно верным вариантом т.к полностью статический класс - это ещё большее зло, а использование его в качестве глобального контейнера с последующим внедреннием в классы через конструкторы или методы-сеттеры сильно раздувает их и жрёт оперативную память.
.
AlkatraZ, Ну так это Zend_Registry и единственное зачем там нужна инициализация обьета класса - это что-бы подцепить ArrayObject.
Я бы вовсе отказался от ArrayObject в пользу магических сеттеров и геттеров php.
.
╭∩╮ (`-`) ╭∩╮
L!MP (24.12.2011/22:26)
AlkatraZ, Ну так это Zend_Registry и единственное зачем там нужна инициализация обьета класса - это что-бы подцепить ArrayObject.
Я бы вовсе отказался от ArrayObject в пользу магических сеттеров и г
Ну да, я же уже писал про это.
Их реализация мне понравилась больше всего, а ArrayObject бывает нужен.
.
╭∩╮ (`-`) ╭∩╮
L!MP (24.12.2011/22:21)
Или даже так (пример из реальной жизни, считай это было вчера):
Есть у меня ServiceLocator, именно этот шаблон я решил использовать для управления зависимостями в своем коде.
Но сам локатор я сделал
У тебя настолько громадный скрипт, что ты не знаешь, где находится нужный тебе класс?
Зачем тебе ServiceLocator?
Этот наворот нужен для фреймворков, как ты знаешь, они все страдают сильной избыточностью потому, что делаются универсальными, автор фреймворка не знает, кто и как его будет применять, потому создает такие навороты.
---
А когда ты пишешь САМ, подобная шелуха в 98% случаев не нужна, ты прекрасно все знаешь и не стоит самому себе морочить голову.
Всего: 30