Статичиеские методы и свойства, Singleton - разъясните

[rotoZOOM]

HraKK я понимаю, что это синглтон холдер, я про это спрашиваю:

public function create($mapper, $input, $services){
        list($http, $logger)=$services->find('http', 'logger');

Почему тогда просто не сделать:

public function create($mapper, $input){
        list($http, $logger)=Services::find('http', 'logger');

 

[HraKK]

rotoZOOM
А вот это не понятно.
Наверно для того чтобы если кто-то изменит название класса Services не придется переписывать проект)))

а так же возможностью выполнять разный функционал на разных вызовах.

Регистр тоже позволит =)

 

[korchasa]

Автор оригинала: HraKK
Регистр тоже позволит =)

Можно, конечно, регистрировать callback'и, и вызывать их по действию.

Registry::registerCallback($resourse = 'db', $action = 'set', $callback = array('MyClass', 'myMethod'));

Но для меня это слишком магическое поведение. "Явное лучше неявного"

 

[Sluggard]

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

Включи мозги. Это решается добавлением 2-х строк в классе LOGGER, не переписывай вызовы инстансов. И потом пиши сколько угодно EXTENDED_LOGGER классов и подменяй их локально. ИМХО, вечный параметр $services только мозолит глаза и доставляет неудобства.

 

[whirlwind]

Код становится монолитным, там где возникает привязка к реализации. Любое имя, упомянутое не в качестве требования интерфейса - это привязка к реализации. Когда вы привязали один класс к другому, вы определили его судьбу на всю жизнь. Это так же неестественно, как и в жизни. Достаточно припомнить сколько у каждого из нас было подружек за всю жизнь. Реализации у них были разные (иначе зачем было их менять), но интерфейс у них у всех был одинаковый

ЗЫ. Кстати, таки да. С трудом могу подобрать ситуацию, при которой невозможно обойтись без сингельтона. Тот же пример с персоной, там сингельтон рядом не валялсо ИМХО

class Person { 
    public function create($mapper, $input){ 
        if($input->valid()){ 
            $mapper->save($input); 
            $this->fireEvent('Person_Saved',$this);
        }
    } 
}

// Или так


class Person { 
    public function create($mapper, $input,IEventListener $observer){ 
        if($input->valid()){ 
            $mapper->save($input); 
            $observer->fireEvent('Person_Saved',$this);
        }
    } 
}

// Или еще более лучший вариант, когда Observer инкапсулирован в $mapper

class Person { 
    public function create($mapper, $input){ 
        if($input->valid()){ 
            $mapper->save($input); 
    } 
}

И навешивай хоть логгеры, хоть редиректоры, хоть написание послания папе римскому.

 

[Alexandre]

от к примеру придется тебе SESSIONS по какой-то причине переименовать на ADVANCED_SESSIONS и тебе придется переписать все места получения этого объекта... у меня я всего лишь перепишу место регистрации сервиса:

в этом случае я напишу класс обертку, хотя какая разница, надо писать так, чтоб потом не переписывать,
и если ты используешь SESSIONS, то уже писать код так, чтоб ADVANCED_SESSIONS стал путем расширения самого класса SESSIONS.

 

[StUV]

очень много воды из-за отсутствия опыта программинга на строготипизированных оо яп или от нежелания этого понять

при явном указании типов аргументов, динамическом связывании или тайп кастинге - вся проблема исчезает, так как совершенно однох...нно где прописывается конкретный тип - в качестве значения аргумента для динамического определения типа или в качестве явного имени класса - при подмене сервиса с возможным появлением конфликтов имен глобальных сервисов - "явный" код фиксится легко - интерпретатор/компилятор сразу скажет где
а если есть какой-нить хитрый механизм резолвинга имен - тут может быть полный пц...

 

[master_x]

StUV
а кто говорил про то, что моя реализация сервисов сможет выжить в строготипизированных языках? мы тут про php вообще-то говорим. можно кстати вопрос? вот ты динамическую типизацию в php считаешь фичей или хаком?

 

[StUV]

вот ты динамическую типизацию в php считаешь фичей или хаком?

фичей при разумном использовании и соответственно, грубым хаком в обратном случае

зы: не могу привести ни одного реального примера, в котором бы эта фича была бы реально нужна и в котором не был бы очевиден по коду онкретный тип каждой переменной в каждой конкретной строке кода

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