Зависимости фасадов Laravel?

Question

Я читал, что не должно быть слишком много зависимостей от одного класса. В одной книге говорится, что 4 зависимости могут быть признаком того, что класс может делать слишком много.

Допустим, я написал класс, который использует 10 зависимостей: 6 классов и 4 фасада. Должен ли я заботиться только об этих 6 классах и разбивать их, или же о 4 фасадах тоже?

Если кто-то хочет знать, как я получаю так много фасадов:

use Input;
use App;
use Session;
use Log;

Те все нужны часто. Я слышал вопрос - зачем мне приложение? Чтобы вызвать функцию:

App::setLocale('lt');

Некоторые говорят, что фасады не являются зависимостями, также здесь:

Полиморфизм и внедрение зависимостей - слишком много зависимостей

Существует множество различных представлений по этому вопросу (когда класс зависит от чего-либо), но зависимости класса обычно рассматриваются как то, что передается в конструктор, то есть то, что необходимо для создания экземпляра класса как объекта.

Я думаю, что я могу сам создать фасад из класса, и я уменьшу зависимости таким образом. Но имеет ли это смысл?

Например, эта статья гласит: мы не должны использовать фасады:

http://taylorotwell.com/response-dont-use-facades/

Из этого я понимаю, что фасады будут не так уж и плохи, но плохо, что класс начинает делать слишком много вещей.

Я говорю о Laravel 4, но, вероятно, то же самое относится к Laravel 5 или другим фреймворкам, которые используют то же самое. Я только что слышал, что Laravel 5 использует не столько фасадов, сколько Laravel 4.

Обновить:

Также я хотел бы получить такой аргумент, чтобы я мог использовать его с другими людьми при обсуждении этой темы. Например, если я скажу - какой-то парень (даже с хорошим профилем stackru) из интернета сказал мне, что фасады плохие, они похожи на глобальные переменные, они сразу скажут - это не то же самое, что глобальные, они насмешливы, вы не должны уход. Также они могут сказать, что это мнение парней. Поэтому я хочу, чтобы сильная сторона защищала себя. Так что я мог бы объяснить это как 2*2 = 4, и никто никогда не мог не согласиться. Или, по крайней мере, близко к этому.

Обновить:

Если это зависимости, и я хочу иметь максимум 4 зависимости для одного класса, у меня есть только одна идея - создавать сгруппированные классы, как дерево классов. Но я заканчиваю со многими классами для маленькой особенности. Как из этих 10 зависимостей, если я хочу иметь максимум 4 зависимости, я думаю, что мне понадобится 3-5 классов вместо 1. Поэтому, если у меня большой проект, у вас будут миллионы маленьких классов. Не будет ли это выглядеть сложнее? Как и у Laravel, я вижу, что у него много классов, а у CodeIgniter гораздо меньше классов, и он выглядит проще для чтения / отслеживания, расширения.

Answer 1

Фасады Laravel, безусловно, являются зависимостями, их предназначение предназначено для контроллеров, при создании сервисов и бизнес-логики вы должны стараться сделать свои зависимости максимально прозрачными.

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

Давайте проиллюстрируем немного этой абстракции:

перед рефакторингом

Class PhotoService {

    protected $photosModel = null;

    public function getPhotos()
    { 
        $photos = Cache::get('photos');

        if (is_null($photos)) {
           return Photo::all();
        }
    }
}

все еще использую фасады, но решаю другие зависимости через МОК

Class PhotoService {

    protected $photosModel = null;

    public function __construct(PhotoInterface $photoModel) {
       $this->photosModel = $photoModel;
    }

    public function getPhotos()
    {
       $photos = Cache::get('photos');

       if (is_null($photos)) {
          return $this->photosModel->getPhotos();
       }
    }
}

решено через МОК

Class PhotoService {

    protected $photosModel = null;

    public function __construct(PhotoInterface $photoModel) {
       $this->photosModel = $photoModel;
    }

    public function getPhotos(CacheInterface $cache)
    {
       $photos = $cache->get('photos');

       if (is_null($photos)) {
          return $this->photosModel->getPhotos();
       }
    }
}

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

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

Этот вид настройки предлагает только преимущества, между ними:

• возможность переключения стратегий кэширования без головной боли
• возможность переключения типов баз данных
• возможность отключать функции, вводя макет через IOC
• поощряет тдд за счет простоты реализации