Как правильно работать с фасадами?

[CoolKid]

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

да, я уверен, что это нужно. Я подумал, где он мне нужен, реализовал и успешно этим пользуюсь.

Вы вообще абстрактно думать умеете?
Абстрактно, не в смысле создания абстракций в коде, а при обсуждении какого-либо предмета в жизни?
Речь ведь не про класс роутинга, не про класс лоадинга, а про вообще любой абстрактный класс, который может у меня быть (абстрактный не в смысле abstract class ClassName, а в смысле любой вообще)
на его месте также может быть класс Config, работающий с конфигами , который может вызываться из любого места системы, читая или добавляя настройки на лету, класс работы с сессией пользователя итд.

 

[Вурдалак]

CoolKid, а тебе нравятся глобальные переменные? Они же такие хорошие, могут вызываться из любого места системы.

 

[CoolKid]

А мне не требуется читать тему. Я — Бог. А ты — говнокодер и быдло. That's it.

Мы сказали. А тем фактом, что ты не признаёшь, что это говнокод, ты его оправдываешь.

CoolKid, а тебе нравятся глобальные переменные? Они же такие хорошие, могут вызываться из любого места системы.

С быдлом не разговариваю, только предлагаю ему сделать мне фелляцию

 

[fixxxer]

Если хочется умеренного говнокода, просто используй (умеренно и аккуратно) DI как сервис-локатор. Единственным "фасадом" тогда будет сам контейнер.

Container::get('Logger')->error('foo');

На такую штуку прекрасно для сторма навешивается документашка через метаданные: http://confluence.jetbrains.com/display/PhpStorm/PhpStorm+Advanced+Metadata (только не нажимай там ссылку How this is implemented, если недавно пообедал).

Laravel style-фасады городить имеет смысл только если ты пишешь на Laravel. С сервис-локатором всегда четко видно дерьмо.

 

[CoolKid]

Мне нравится как это реализовано в Laravel и хочу в моем инструменте реализовать это схожим образом.
Собственно поэтому вопрос и возник.
Спасибо за наводку.

 

[Absinthe]

Мое мнение однозначно - http://symfony.com/doc/current/book/service_container.html
Хотя и не претендует на звание единственно верного. Т.к. многим это кажется слишком сложным.
Тем не менее контейнер заставляет явно декларировать зависимости, что в итоге делает код более чистым, более слабосвязанным и более простым для поддержки.

Ты тоже оправдываешь свой гавнокод свой ленью?... Все ясно

Загружай маршруты из конфига или датабазы. Никто не заставляет для каждого маршрута отдельный метод создавать. Это же не контроллер.

Что за упертость?
Средства выбираются под задачу. И если говнокод работает лучше, стоит дешевле, пишется приятнее и поддерживается проще, то почему бы не говнокодить?

 

[hell0w0rd]

Absinthe, а что за распространенное мнение, что DI - это сложно? Особенно с аннотациями

 

[Absinthe]

Absinthe, а что за распространенное мнение, что DI - это сложно? Особенно с аннотациями

Это просто, но долго.

 

[keltanas]

И если говнокод работает лучше, стоит дешевле, пишется приятнее и поддерживается проще

Скажи честно, где ты выдел такой гавнокод?

Это просто, но долго.

Что долго? Все уже готово. Бери и используй.

 

[Absinthe]

Скажи честно, где ты выдел такой гавнокод?

Laravel, Yii, Kohana и т.д.
В них академическая правильность кода приносится в жертву удобству и скорости разработки.

Что долго? Все уже готово. Бери и используй.

Использовать долго.

 

[hell0w0rd]

Absinthe, да как долго-то?))

/**
* @Inject("doctrine.orm.enitity_manager")
* @var EntityManager
*/
private $em;

/**
* @Service("app.image_manager", arguments={"@doctrine", "@imagine", "%logo_min_size%"})
*/
class ImageManager {}

@Sam Dark называет это выпячиванием внутренностей фреймворка, а по моему это удобнее кучи статики, которая где-то бустрапится, а потом магически отрабатывает

 

[WMix]

hell0w0rd, палка о двух концах, с одной стороны хочу видеть все зависимости в одном месте, с другой стороны только там где используется. Какие классы используют ту или иную модель?

...
'var' => function( $sm ){ 
  return new Xyz($sm->get('EntityManager') );
}

 

[keltanas]

WMix, Какие зависимости нужны конкретному классу, решает программист/архитектор этого класса и предлагает передавать их через конструктор, сеттер или записать напрямую в св-во.
А контейнер только помогает по быстрому настроить конфигурацию, чтобы эти зависимости удовлетворить.
Непосредственно с контейнером работает только контроллер.
Да, видимо, продумывать зависимости каждого класса дольше, чем доставать зависимости из синглтона там, где захотелось, но это позволяет подумать, нужна ли та или иная зависимость классу, или нет?

 

[fixxxer]

Absinthe, вот не надо только про yii Там как раз из-за архитектурных ограничений многие простые вещи становятся невозможными без говнохаков, тот же мастер-слейв. Я понимаю твою мысль и с ней согласен, но тут надо четко разграничивать код конкретного приложения "здесь и сейчас" (скажем, относительный говнокод в контроллере конкретного приложения - это 100% пофиг) и реюзабельные вещи.

Absinthe, да как долго-то?))

/**
* @Inject("doctrine.orm.enitity_manager")
* @var EntityManager
*/
private $em;

/**
* @Service("app.image_manager", arguments={"@doctrine", "@imagine", "%logo_min_size%"})
*/
class ImageManager {}

@Sam Dark называет это выпячиванием внутренностей фреймворка, а по моему это удобнее кучи статики, которая где-то бустрапится, а потом магически отрабатывает

Мы тут с Вурдалаком как раз недавно обсуждали, что такие аннотации ничем не лучше фасадов.

 

[Вурдалак]

Если инжектить через конструктор, пусть даже через аннотацию, то по крайней мере все зависимости будут на виду.

 

[fixxxer]

Через конструктор или, пожалуй, сеттер-метод - окей. Я про это:

/*** @Inject("doctrine.orm.enitity_manager")
* @var EntityManager
*/
private $em

 

[fixxxer]

Хотя и через конструктор мне не очень нравится. В конструкторе должны быть описаны интерфейсы, а какая реализация интерфейса нужна - это должно настраиваться на уровне конфигурации DI, а не зашиваться в классе. Именование зависимостей - это маскировка, а не решение: ну будет в 100 классах пробито в комментариях одинаковое имя, и что дальше?

 

[hell0w0rd]

fixxxer, @Inject используем в проекте, если либу пишем - yaml с параметрами. Никаких там сложностей тоже нет, особенно учитывая поддержку IDE
Особенно в проектах удобно всякие @Tag, @FormType

 

[Absinthe]

@Sam Dark называет это выпячиванием внутренностей фреймворка

Выпячивание внутренностей фреймворка как раз в Yii или Laravel: дергаем фреймворк за контейнер и что-то из него тянем. В результате жестко привязаны на контейнер в обоих случаях.
Код на Symfony же часто не зависит от фреймворка совсем (на уровне сервисов) и может быть использован в коде с другими фреймворками без каких-то изменений кода. Но часто ли мы меняем фреймворк с сохранением кода?

Absinthe, да как долго-то?))

В данном случае ты получаешь зависимости прямо из своего кода. Разве это DI?

 

[hell0w0rd]

Absinthe, моя мысль сводится к тому, что использование DI, вместо фасадов, или еще чего - также просто. Когда мы пишем код проекта - мы можем свободно использовать приведенные мной аннотации и все будет работать, все будет красиво. Если мы пишем абстрактный бандл - описываем конфигурацию в yaml, что также не слишком сложно и выкладываем.
В итоге как правильно сказал keltanas - проблема в том, что большинству (кому контейнер кажется сложным) проще зависимости тащить прямо в классе из фасадов, не задумываясь заранее, что является зависимостью, а что нет.