Правильная архитектура CMS, без static методов, с глобальным хранилищем и инициализатором Классов.

[artoodetoo]

fixxxer, очень странно слышать такие речи.

Во первых вы убежали от своей начальной формулировки. Некрасиво! Таки глобальные переменные или суперглобальные?

Во вторых, в сервис-локаторе в момент вызова может срабатывать некая логика. В том числе и логика контекста. (не напоминает ваш Phemto? тот же фиг, только вид сбоку). Может быть ленивая инициализация, что угодно! А в суперглобальной переменной значение уже должно быть определено - без вариантов.

Как именно реализовать DI непринципиально. Лично мне про DI докладов не делать, а читать очередной срач скучно.

 

[artoodetoo]

p.s. Кто сказал "регистри"??? Вы со своими демонами сами разберитесь

 

[fixxxer]

Таки глобальные переменные или суперглобальные?

лол что

может срабатывать некая логика

и что, как это поможет?

class Foo {
     function getDb() {
         return ServiceLocator::get('db');
     }
}

а вдруг теперь я хочу чтобы в $Foo1 = new Foo и $Foo2 = new Foo были разные db. По некоторой внешней логике. Сколько мне дерьма перелопачивать?

Про ленивость то ежу понятно но это не имеет прямого отношения к управлению зависимостями, это всего лишь оптимизация.

Окей, делаем тогда так:

function db() {
static $db;
if (!isset($db)) { ... lazy init ... }
return $db;
}

и дергаем везде db(). То же самое, только без притягивания за уши ООП-подобной эмуляции глобалсов Дальше то что?

 

[Lionishy]

вдруг теперь я хочу чтобы в $Foo1 = new Foo и $Foo2 = new Foo были разные db

Если Вы не умеете проектировать объектные приложения, то, да, согласен, никакой локатор Вам не поможет.

 

[fixxxer]

 

[artoodetoo]

ну и чем это отличается от global $db, $db2?

И чем такой сервис локатор отличается от $GLOBALS?

Вообще в типичных подобных регистри есть метод set

Мой щенок похож немного на бульдога и на дога, на собаку водолаза и на всех овчарок сразу А еще он крестиком вышивает.

У вас есть отличная картина мира, не буду её мутить.

 

[kryoz]

Кэп говорит, что оперировать надо абстракциями, т.е. интерфейсами. Тогда всё будет понятно.
А по собственному опыту лучше всего мозги прочищают от непонимания и сомнений в ООП юнит-тесты.

 

[fixxxer]

artoodetoo
Ну-ка рассказывай, чем отличается global $db от $GLOBALS['db']. Внимательно слушаю.

А еще расскажи, как ты без сеттеров в этом своем локаторе будешь писать юнит-тесты. Тоже внимательно слушаю

 

[artoodetoo]

Хорошо тебя зацепило Рассказываю:
1. global смотрит на один уровень выше по стеку вызовов. Если между определением $var и его использованием есть два вызова функций, то придется прописать global $var в каждой функции, даже если она сама не эту переменную не использует. Суперглобальные переменные видны где угодно. Их конечное количество и программист не может сам добавить новые.
Это азбука PHP. Хотя зачем знать алфавит, если пишешь докторскую. Согласен, чо.

2. Как устроен мой локатор в твоем мирке знать не обязательно. Это черный ящик. Ты должен довериться соглашению, что на пароль 'db' он выдаст правильный отзыв - объект с требуемым интерфейсом. А не доверяешь, давай до свидания! Абсолютно так же ведут себя все DI containers как бы сладко они не были намазаны медом.
Тесты выглядят также как любые другие тесты.

 

[Вурдалак]

1. global смотрит на один уровень выше по стеку вызовов. Если между определением $var и его использованием есть два вызова функций, то придется прописать global $var в каждой функции, даже если она сама не эту переменную не использует. Суперглобальные переменные видны где угодно. Их конечное количество и программист не может сам добавить новые.
Это азбука PHP. Хотя зачем знать алфавит, если пишешь докторскую. Согласен, чо.

LOOOOOOOOOOOOOOOOOL. Чувак, ты эпично по*****л сам себя.

 

[artoodetoo]

Я могу привести пример реализации локатора, только зачем? Детали отвлекают от главного. LOL. Я лучше сосредоточусь на твоем поражении )))

 

[Вурдалак]

Вурдалак, тебе показать или сам тесты прогонишь?

xxx@xxx:/var/xxx$ php globals.php 
<?php

readfile(__FILE__);

function a() {
	b();
}

function b() {
	c();
}

function c() {
	global $x;
	var_dump($x);
}

$x = '<...>';
a();

string(5) "<...>"

 

[fixxxer]

лол, ладно, пациент сам себя поимел, с ним все ясно.

для остальных читателей спешу заметить, что DI отличается тем, что использование контейнера или явная передача нужного объекта делается извне. Ровно того же можно добиться с сервис локатором, если везде позволять передать зависимости в конструкторе или сеттером, а локатор дергать только если свойство, хранящее ссылку на зависимость, не определено. Но это чревато массой бойлерплейт кода (или трудноотлаживаемой магией в __get/__call).

 

[kryoz]

http://www.php.net/manual/ru/language.variables.scope.php

 

[artoodetoo]

Ладно чуваки, я был неправ. плохо знаю глобалы, т.к не использую. Увлекся.
peace!

 

[Фанат]

peace!

Вот я тоже думаю, что дискуссии стоит сбавить обороты. С обеих сторон.
с одной стороны, небольшая пикировка мотивирует оппонентов, идёт на пользу дискуссии. Но если она скатывается в тупое хамство - это идёт уже во вред.
Так что давайте держаться в рамках.

 

[Вурдалак]

хрень высосанная из пальца. нормальные psr-0 и psr-1, дальше пошла ерунда - где-то в районе psr-2 произошел плавный переход от "давайте все делать так, как делает большинство" к "давайте все делать так, как делаю я".

Я понимаю, что PSR-3 фактически пропихнул автор Monolog'а, но я не вижу в этом ничего принципиально плохого. Как сейчас делать логгирование в библиотеках? Делать каждой свой логгер? Это компромисс.

P.S. Просьба вынести посты о PSR-3, включая мой, в отдельную ветку.

 

[uid]

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

 

[fixxxer]

Вурдалак
В том и проблема, что он пропихнул далеко не самую удачный интерфейс, с дебильными названиями методов (методы должны быть глаголами, блджад!) и дурацким array context с дурацкой магией.

 

[Вурдалак]

fixxxer, меня успокаивает мысль о том, что это просто сахарок для $logger->log(). А что магического в абсолютно тупом context?