Зависимости фасадов Laravel?
Я читал, что не должно быть слишком много зависимостей от одного класса. В одной книге говорится, что 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.
Обновить:
Также я хотел бы получить такой аргумент, чтобы я мог использовать его с другими людьми при обсуждении этой темы. Например, если я скажу — какой-то парень (даже с хорошим профилем stackoverflow) из интернета сказал мне, что фасады плохие, они как глобальные переменные, они сразу скажут — это не то же самое, что глобальные, они насмешливы, вы не должны уход. Также они могут сказать, что это мнение парней. Поэтому я хочу, чтобы сильная сторона защищалась. Так что я мог бы объяснить это как 2 * 2 = 4, и никто никогда не мог не согласиться. Или, по крайней мере, близко к этому.
Обновить:
Если это зависимости, и я хочу иметь максимум 4 зависимости для одного класса, у меня есть только одна идея — создавать сгруппированные классы, как дерево классов. Но я заканчиваю со многими классами для маленькой функции. Как из этих 10 зависимостей, если я хочу иметь максимум 4 зависимости, я думаю, что мне нужно 3-5 классов вместо 1. Поэтому, если у меня большой проект, у вас будут миллионы маленьких классов. Не будет ли это выглядеть сложнее? Как и у Laravel, я вижу, что у него много классов, а у CodeIgniter гораздо меньше классов, и он выглядит проще для чтения / отслеживания, расширения.
Решение
Фасады 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
- поощряет тдд за счет простоты реализации
Другие решения
Других решений пока нет …