Ответ Тейлора на статью "Не используйте фасады"

Статистика: Символов — 3 198/2 737 без пробелов (2 857/2 444 без кода):, слов — 414
Разметка: Wiki
Сегодня после обеда на Reddit появилась ((http://programmingarehard.com/2014/01/11/stop-using-facades.html статья)), которая предостерегает пользователей Laravel от использования так называемых "фасадов" (!!(tl_note) ((ВП:фасад (шаблон проектирования)==шаблон проектирования)) в ООП - //прим. пер.//!!).

В случае с Laravel, фасады - это то, что используется, когда вы делаете, на первый взгляд, статический вызов метода класса. Например:
%%(php)
  Route::get('/', 'HomeController@showWelcome');
%%

Как многие из вас уже знают, этот вызов можно также записать следующим образом:
%%(php)
  $app['router']->get('/', 'HomeController@showWelcome');
%%

Таким образом код становится проще, ведь фасады - синтаксический сахар для //обнаружения услуг// (service location). Когда вы обращаетесь к фасаду он извлекает связанный класс из ((док4:ioc контейнера IoC Laravel)) и вызывает требуемый метод его экземпляра. Фасады предоставляют очень сжатый, выразительный синтаксис, одновременно позволяя вам тестировать код во всех деталях.

Несмотря на это, такой подход для //обнаружения услуг// может привести разработчика к исплоьзованию плохих архитектурных решений. К примеру, так как услуги очень легко "обнаружить", то зона ответственности классов может неправомерно расширяться. Обычно класс должен обладать малой и строго очерченной зоной ответственности, так как его будет проще понять, протестировать, отладить и так далее. Однако если вы используете фасады для работы с ((док4:queues очередями)), отправки e-mail, ((док4:validation проверки ввода)) - и всё это в одном классе, то трудно понять, за что же отвечает такой класс. **Он заботится слишком обо многих вещах.**

Можно использовать фасады и при этом поддерживать узкую и сфокусированную зону ответственности каждого класса, но некоторые предпочитают следовать принципу внедрения зависимостей в конструктор - это позволяет создать зависимость при создании экземпляра данного класса. Это явное объявление зависимости, т.е. именно то, что **нужно** для вашего класса, поэтому она позволяет понять, что ваш класс **делает**.

До сегодняшнего дня для добавления класса для использования в фасаде требовалось сделать явные регистрации в ((док4:ioc контейнере IoC)), но теперь внедрить зависимость стало так же просто, как использовать сам фасад. Для этого применяются //подсказки типов// ([[phpdoc:language.oop5.typehinting type hinting]]) на класс, к которому обращается этот фасад - такая зависимость будет автоматически добавлена в контейнер и будет разрешена, когда это потребуется.

Скажем, вам требуется добавить экземпляр %%(php)Session%% внутрь контроллера. Просто сделайте это:
%%(php)
  <?php
  class HomeController extends BaseController {

    public function __construct(Illuminate\Session\Store $session)
    {
      $this->session = $session;
    }

  }
%%

Больше не нужно какой-то дополнительной настройки. Так как все контроллеры автоматически извлекаются из IoC, то экземпляр %%(php)Session%% будет автоматически внедрён в качестве его зависимости. Внедрение зависимости от класса в фасад так же просто сделать, как и использовать сам фасад! Так что если вам нравится использовать фасады - продолжайте это делать, просто следите за зоной ответственности своих классов. А если вам больше нравится внедрение зависимостей через конструктор - тогда теперь всё стало куда проще!

Если вы не уверены, какой класс следует обозначить в подсказке типа, обратитесь к ((http://laravel.com/docs/facades#facade-class-reference руководству фасадов и классов)) в документации Laravel.

Приятной работы!