static VS Singelton

Духовность™

Продвинутый новичок
static VS singleton

Рушу догмы, возникшие и оставшиеся в моей голове на этапе освоения ООП, приходится сталкиваться с противоречиями и, казалось бы, тривиальными вопросами.

Представьте объект Http_Request, в принципе простую обёртку над $_REQUEST. Данный класс у меня изначально был Singelton-ом, ибо в приложении всегда должен быть только один объект Request, что, думаю, справедливо.
Так же Singelton у меня Http_Response, Session и др..

Сейчас подумал следующее: фактически, одиночку я использую для того, что бы иметь хранилище данных, гарантирующее, что данные всегда будут лежать в одном месте, в одном массиве. И всё. Сам объект одиночки не хранит никаких состояний в оперативной памяти. Фактически, вместо одиночки можно использовать статические свойства:

PHP:
class static_class
{
    protected static $data = array();

    public function __get($key)
    {
        return isset(self::$data[$key]) ? self::$data[$key] : null;
    }

    public function __set($key, $value)
    {
        self::$data[$key] = $value;
    }
}

$my = new static_class();
$my->var = 111;

$my2 = new static_class();
echo $my2->var; // 111

$my2->var = 'foo';

echo $my->var; // foo
т.е. разница стирается между

PHP:
Http_Request::getInstance()->var
и
PHP:
$obj = new static_class();
$obj->var;
данное "открытие" привело меня в тупик.

Если мы, например, будет реализовывать регистр, аналог GLOBALS, то что нам лучше подайдет - одиночка или класс со статическими свойствами?
 

.des.

Поставил пиво кому надо ;-)
Тебе бы полезным практическим делом заняться. Тогда и понимание придет. Теория ради теории хороша для философов.

Ты покажи практическую задачу которую ты пытаешься решить, тебе и подскажут ответ.
 

whirlwind

TDD infected, paranoid
getInstance в сингельтоне сделано не для задротства при написании, а для возможности передачи объекта _при сохранении единичности_ инстанса. Каждый статический вызов усиливает coupling _классов_. Каждая передача инстанса усиливает coupling _интерфейсов_. Класс привязка к интерфейсу и реализации. Интерфейс - привязка только к интерфейсу.
 

HraKK

Мудак
Команда форума
А я бы не использовал ни одиночку не статику тут. Почему бы не сделать нормальный класс?
 

whirlwind

TDD infected, paranoid
HraKK в том то и смысл, что при связывании интерфейсов, пользовательский класс абсолютно равнодушен к тому, как реализован используемый класс. Я такие вещи впрыскиваю в контроллер в виде контекста запроса.
 

Духовность™

Продвинутый новичок
А я бы не использовал ни одиночку не статику тут.
где тут?

Тебе бы полезным практическим делом заняться. Тогда и понимание придет. Теория ради теории хороша для философов.
я программирую, с чего ты взял, что я не практическим делом занимаюсь? рррр!!!

whirlwind
сохранении единичности_ инстанса -это и есть состояние. да?
 

whirlwind

TDD infected, paranoid
triumvirat не обязательно. Единичность - это одно из нефункциональных требований. Классы реализуют функциональные требования.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
а в чем вообще смысл использования классов для доступа к суперглобальным переменным?

-~{}~ 02.04.10 17:01:

вот зачем обращаться к данным через Http_POST::getInstance()->var, а не
input_filter(INPUT_POST,'var',FILTER_VALIDATE_...)
?
 

fixxxer

К.О.
Партнер клуба
>> ну наверно потому, что иногда приходится Http_Request вызывать в нескольких разных местах. И Http_Request::getInstance() с этим прекрасно справляется.

>> а в чем вообще смысл использования классов для доступа к суперглобальным переменным?

нормальных экземпляров (а не satic/singleton) - именно поэтому. Чтобы не возникало желания обратиться там где это не нужно.

Статики-синглтоны же ничем не лучше глобалсов по большому счету.
 

korchasa

LIMB infected
Автор оригинала: whirlwind
triumvirat не обязательно. Единичность - это одно из нефункциональных требований. Классы реализуют функциональные требования.
Как это? Требование того, что object::getInstanse() должен возвращать ссылку на один и тот же объект не является функциональным?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
>Статики-синглтоны же ничем не лучше глобалсов по большому счету.
в объекте данные могут быть уже валидированы хотя бы, приведены к ожидаемой структуре, в этом может быть смысл

но мне не понятен смысл классов с нечеткой структурой, используемых для доступа к REQUEST-полям
не лучше ли создавать смысловые объекты, заполняя их данными, вроде
$user->name = filter_input('name');
и работать уже с ними, безо всяких GET/POST?
 

zerkms

TDD infected
Команда форума
но мне не понятен смысл классов для доступа к REQUEST-полям
например - тестирование. объект запроса заполняется произвольными данными для тестирования, объекты тестирования ни о чём не подозревают.
аналогично - организация возможности запуска приложений из разных сред: mod_php/cli, когда на этапе бутстраппинга (или ещё где-то, не важно) создаётся объект запроса: а на этом этапе мы знаем о том, что запросы бывают разные, и дальше работаем с объектом; с другой стороны - клиенты для этого объекта (контроллеры, например) не знают откуда он берётся, какими данными и как заполняется.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
zerkms
а для тестирования может заполняться данными напрямую смысловой объект или массив $_POST?
 

fixxxer

К.О.
Партнер клуба
я попробую другой пример привести, а то когда все архитектурные вопросы сводятся к тестированию это вызывает недоверие :)

например, входные параметры может возникнуть необходимость прочитать

1) обычным для веба способом из get/post
2) xml/json-апи - из распарсенного тела запроса
3) из аргументов командной строки

при этом я просто пишу соответствующие реализации RequestInterface и определяю в соответствующих конфигах IoC их использование, больше ничего не меняется.
 

zerkms

TDD infected
Команда форума
grigori
вообще-то заполнять $_POST в тестах несколько геморно, потому как после каждого кейса придётся восстанавливать его значения.

я попробую другой пример привести
а у меня вторая половина как раз и была про "разные типы запросов", вот только после слова "тесты" (FFFFFFUUUUUUUUUUUUUU) уже дальше всё остальное плохо различимо :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
понятно, т.е. случай, когда программа пишется под неопределенную среду исполнения -
"клиенты для этого объекта (контроллеры, например) не знают откуда он берётся" - главная цель создания отдельного объекта запроса
хм, у меня таких задач не бывает просто - всегда знаю, из браузера вызываться будет, или из крона
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
>после каждого кейса придётся восстанавливать его значения.
мне кажется, состояние объекта запроса восстанавливается копированием (клонированием). для массива это сложней?
 
Сверху