Интерфейсы и слабая связность

статья: https://laravel.ru/docs/v5/contracts
Цитирую (мои комментарии курсивом):

Но для начала рассмотрим код с сильной связностью с реализацией кэша. Рассмотрите следующее:

Код (PHP):

1. <?php namespace App\Orders;
2.  
3. class Repository {
4.  
5.   /**
6.    * Кеш.
7.    */
8.   protected $cache;
9.  
10.   /**
11.    * Создание нового экземпляра репозитория.
12.    *
13.    * @param  \SomePackage\Cache\Memcached  $cache
14.    * @return void
15.    */
16.   public function __construct(\SomePackage\Cache\Memcached $cache)
17.   {
18.     $this->cache = $cache;
19.   }
20.  
21.   /**
22.    * Получение заказа по ID.
23.    *
24.    * @param  int  $id
25.    * @return Order
26.    */
27.   public function find($id)
28.   {
29.     if ($this->cache->has($id))
30.     {
31.       //
32.     }
33.   }
34.  
35. } 

В этом классе код сильно связан с реализацией кэша, потому что мы зависим от конкретного класса Cache данного пакета. Если API этого пакета изменится, наш код должен также измениться.
Аналогично, если мы хотим заменить нашу базовую технологию кэша (Memcached) другой технологией (Redis), нам придётся вносить изменения в наш репозиторий.
(моё прим. - здесь пока всё ясно, я со всем согласен)
Вместо такого подхода, мы можем улучшить наш код, добавив зависимость от простого интерфейса, которой не зависит от поставщика:
(моё прим. - те предлагают создать собственный интерфейс)

Код (PHP):

1. <?php namespace App\Orders;
2.  
3. //Contracts - это так в ларавель называются интерфейсы
4.  
5. use Illuminate\Contracts\Cache\Repository as Cache; 
6.  
7. class Repository {
8.  
9.   /**
10.    * Создание нового экземпляра репозитория.
11.    *
12.    * @param  Cache  $cache
13.    * @return void
14.    */
15.   public function __construct(Cache $cache)
16.   {
17.     $this->cache = $cache;
18.   }
19.  
20. } 

Теперь код не привязан к какому-либо определённому поставщику, и даже не привязан к Laravel. Контракт не содержит никакой конкретной реализации и никаких зависимостей. Вы можете легко написать свою реализацию любого контракта, что позволяет вам заменить реализацию работы с кэшем, не изменяя ни одной строчки вашего кода, работающего с кэшем.

Я правильно понял что они предлагают просто написать свою обёртку поверх, подключаемой библиотеки. Которая будет реализацией, интерфейса, который мы используем в конструкторе при внедрении. И получается если апи библиотеки изменится, или мы вообще заменим библиотеку , то соответственно придётся переписывать нашу обёртку. Тут я даже не знаю что проще - переписывать обёртку(реализация нашего интерфейса), или лезть править в вызывающий код. Преимущества интерфейсов вообще не понятны, во делов то поменять уточнение класса, там где он внедряется.

 

Там в примере во втором коде интерфейс используют в конструкторе. Подразумевается что те кто читают эту статью, знают что такое интерфейс в PHP ну или в других ЯПах. Поэтому там не объясняется что это такое.