N, да я так и планирую) но там надо связать около 8 таблиц и думаю чистый sql быстрее отработает. В идеале бы найти решение на Eloquent. Например чтобы он не в обьекты складывал выборку, а в массив
camradee, этому есть обьяснение. Пространства имен создаются на этапе компиляции в байт код, а не во время выполнения. Поэтому в момент выполнения кода так происходит.
Tokenchik, Отрывок из книги.Обычно зависимость - это интерфейс, который имеет несколько реализа-
ций. Использование реальных реализаций этого интерфейса во время unit-
тестирования - плохая идея, поскольку там могут проводиться те самые опера-
ции ввода-вывода, замедляющие тестирование и не дающие провести тести-
рование этого модуля в изоляции. Прогон unit-тестов должен быть быстр как
молния, поскольку запускаться они будут часто и важно, чтобы разработчик
запустив их не потерял фокус над кодом. Написал код - прогнал тесты, еще
написал код - прогнал тесты. Быстрые тесты позволят ему оставаться более
продуктивным, не позволяя отвлекаться. Решение в лоб задачи изоляции
класса от зависимостей - создание отдельной реализации этого интерфейса,
предназначенного просто для тестирования.
Так вот суть в том, чтобы точечно проверить текущий класс на его функциональность. Моки удодно делать на основе общего интерфейса. Всё мокать не нужно. Но если ваш класс работает с апи, бд, большим обьемом данных. То такая зависимость это плохо.
Цель теста проверить текущий класс на соответствие требований. А какие данные настоящие или фейк это не важно.
Unit Test - модульное решение. Ваш класс можно считать как отдельный , независящий от другого мира. Он не должен знать сам по себе внешние данные и зависеть от них. Суть этих тестов именно проверит функциональность модуля
Могу с уверенностью сказать, что для однотипной фабрики не стоит использовать switch !В его случае именно такая. Все типы это Компоненты наследованные от общего интерфейса. Дурной том в такой случае использовать switch. Если был фабричный метод, ок согласен. Но не тут.
BoShurik, вы путаете простую фабрику от статичной. Как минимум в статичной есть статический метод. Который и будет генерировать новые обьекты. Собственно там так и написано. Простая фабрика - Она отличается от Статической Фабрики тем, что собственно не является статической
Можно упростить гораздо. Без swith. Просто создавай new "{$component}Component". Можешь даже почитать https://refactoring.guru/ru/smells/switch-statements. Раздел лечение, второй пункт. Первый вариант ничем не отличается от второго. Только добавить проверку на существование, и то можно сделать на уровне выше, в автозагрузчике.
public function createInstance($component): ComponentInterface
{
return new "{$component}Component";
}
WapSter, я не пойму где в коде делается проверка. ОБычно делают так: вещают на документ событие, проверяют разрешение и добавляют класс desc или mob в боди. Тут такого нету
WapSter, js есть конечно :D Но я говорю именно про меню. Если есть preventDefault(). То не пойму почему только на мобильном. Обычно добавляют в боди классы mobile и т.д. Но тут нету ни какого ориентира. Можешь подсказать пожалуйста какую-нибудь библиотеку на js для таких меню?