Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Ну, если я верно понял суть вопроса, то суть, интерфейса состоит в том, что все классы реализующие интерфейс имеют одинаковый интерфейс 
Ну например в одной реализации WebMoney() есть метод какой-то, узнать оплатил или передумал чел, и назван он к примеру - check($id), где $id - идентификатор транзакции в webmoney. И вот сайт весело пользует это дело. Но тут захотелось работать с PayPal ну или еще чего. Реализуем это дело, но в этот раз называем метод проверки - check(), т.е. предполагается, что ид транзакции был задан где-то в другом месте. Далее меняем привязку в контейнере и с удивлением обнаруживается, что код сломался, ибо старый код (ответственный за вызов check) не знает (правда реализация PayPal может сама где-то его брать, а что если этих разных реализаций - штук 20 и каждая из них реализована по-своему?), что ид надо задавать где-то в другом месте и пытается с этим работать. Получаем ошибку.
А если использовать интерфейс, то там точно описаны названия методов, параметры получаемые этими методами, требования к реализации методов (например метод должен возвращать результат от -1 до 1) и т.д. Т.е. если следовать логике ООП реализуя интерфейс - гарантированно соблюдаешь правила игры и вероятность, что код сломается из-за изменения одной строчке минимизируются.
Есть куча объектов, реализующих класс животное, а они могут кушать, двигаться, ... Каждая реализация этого интерфейса заставляет их по-разному двигаться, кушать... Т.е. в одном месте в проге какой-то метод, ответственный за движения, будет точно знать, что в переданной ему коллекции животных есть метод move (например), а уже каждая конкретная реализация в этой коллекции в зависимости от того как должна животика двигаться - двигается. Если этого нет, то возникает куча сложностей отслеживания как называется метод заставляющий двигаться (лошадка - беги, рыбка - плыви), какие принимает параметры, какие выбрасывает исключения и прочее и прочее и прочее. Короче интерфейсы здорово облегчают жизнь. Но вот другая сторона интерфейсов, а именно проектирование - это отдельная ветвь науки
Имхо, таким образом осуществляется подмена классов (полиморфизм т.е.). Например написал ты интерфейс для онлайн оплаты товара (рассылки смс и т.д.). Реализуешь их с помощью конкретных классов (например для яндекса, для монеты, для API конкретного банка). Заказчик за ,3 секунды до подписания акта сдачи проекта решает изменить способ оплаты с яндеса на монету (или наоборот или еще на что-то). Если есть готовая реализация ты просто в одном месте программы изменяешь строчку и все готово.
А если внедрять напрямую класс в метод (конструктор) то ты жестко привязан к конкретной реализации. Можно конечно быстренько найти все use и внедения и заменить (тут главное - не пропустить где-то, и не оставить старую реализацию, на что заказчик может обидеться и реализовать свою версию секаса , репутация опять-таки) на нужное. Но это нарушает всемирную гармонию энергии 
Ну а обычные модели и прочие вещи, которые точно не будут меняться (т.е. не реализуют интерфейс, который можно вот так просто подменить) внедряются через сервис-контейнер.
Повторюсь - это то, что я понял читая доки.
Нашел вроде, как оно работает. В доке на 5.3 в разделе сервис-контейнера написано:
There is no need to bind classes into the container if they do not depend on any interfaces. The container does not need to be instructed on how to build these objects, since it can automatically resolve these objects using reflection.
Т.е. при помощи рефлексии контейнер автоматически понимает, что требуется методу контроллера и передает туда нужные данные.
Есть документация для 5.2 на laravel.su - точно.
Возможно, и для 5.3 на github, хотя гайды вряд-ли успели перевести.
А что касается уверенного использования в работе, то, я думаю, можно и не читать про сервис-контейнеры. Вы же сами "полезли" на этот уровень.
Так там-же все крутится вокруг этих сервис-провайдеров, говорят, что это чуть ли не самая главная фишка (где-то читал). Да и надо понимать как оно работает, чтобы использовать максимально все возможности. Можно конечно и старый-добрый new App\Task() использовать, но тогда зачем это все?
Ради интереса решил обратиться к первоисточнику. Ссылка на гитхабе, на документацию не работает. Оказалось, что последняя версия этого гайда написана к версии Laravel 5.1.
Там все то-же самое, что и в переведенной версии. А вот в самих исходниках внесены изменения в связи с приведением к текущей версии Laravel, где из app/Providers/RouteServiceProvider.php строка $router->model('task', Task::class); в методе boot удалена. Куда она перенесена и как это теперь работает - не понятно.
Интересно, планируется ли перевод доки на Laravel 5.3? Ибо с аглицким к стыду своему - не очень хорошо.
Да, в гайде все понятно, кроме этого момента (ну и что гайд не совпадает с исходным кодом на гитхабе, т.к. указанной в гайде привязки в сервис контейнер модели - нет, это как минимум). Совершенно не понятно, как сервис-контейнер внедряет туда экземпляры этих классов, т.к. они нигде не описаны как это в гайдах описано, дабы внедряться автоматом. Просто объявлены в качестве параметров методов и каким-то образом туда передаются.
Спасибо за наводку на книгу. Хотя это странно, что для того, чтобы пользоваться фреймворком надо прочитать какие-то книги дополнительные. С Kohana и YII достаточно было прочитать официальную документацию, чтобы уверенно использовать в работе (хотя да, согласен много чего в книгах полезного, не очевидного бывает). Но чтобы узнать как работает базовый функционал (а не рецепты какие-либо) - читать дополнительную литературу...
Короче, как я понимаю - как это работает не знает ни кто. Магия...
Добрый день.
Начинаю изучать, ничего не понимаю пока. Прочитал "Углубленный быстрый старт" , потом про сервис контейнеры и поставщики услуг. Вернулся к углубленному старту, скачал себе локально, чтобы разобраться.
Про удаление задачи пишут, что в "app/Providers/RouteServiceProvider.php в методе boot()" надо добавить строку:
$router->model('task', 'App\Task');Но там такой строки нет, тем не менее в метод destroy() контроллера TaskController передается экземпляр App/Task как он туда попадает?
То-же самое касается и внедрения TaskRepository в конструктор этого-же контроллера.
Ни в одном из провайдеров, зарегистрированных в config/app.php нет упоминаний об App/Task (только в AuthServiceProvider регистрация TaskPolicy), ни TaskRepository.
В разделе Маршрутизация (глава - Привязка модели) рассказывается про внедрение, но вот как выглядит RouteServiceProvider, скачанный из GitHub к главе Углубленный быстрый старт:
class RouteServiceProvider extends ServiceProvider
{
/**
* This namespace is applied to the controller routes in your routes file.
*
* In addition, it is set as the URL generator's root namespace.
*
* @var string
*/
protected $namespace = 'App\Http\Controllers';
/**
* Define your route model bindings, pattern filters, etc.
*
* @param \Illuminate\Routing\Router $router
* @return void
*/
public function boot(Router $router)
{
//
parent::boot($router);
}
/**
* Define the routes for the application.
*
* @param \Illuminate\Routing\Router $router
* @return void
*/
public function map(Router $router)
{
$router->group(['namespace' => $this->namespace], function ($router) {
require app_path('Http/routes.php');
});
}
}Короче - ничего не понимаю 
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)