Interface vs Provider, есть ли разница при реализации нижеописаного функционала? Допустим на примере класса кэширования.
Нужно написать функционал для нескольких движков кэширования (Redis, File, SQLite).
С одной стороны можно написать CacheProvider описывающий общие методы для кэширования (get, set) и подключающий нужные "драйверы" через именованные конструкторы
Примерно вот так я вижу использование:$cache= CacheProvider::redis(array $cfg) //@return Redis instanc
//Ил
$cache = CacheProvider::driver(string CacheProvider::DRIVER_REDIS, array $cfg)
Минусы которые я вижу:При создании нового драйвера, нужно обновлять класс Cache и добавлять новый конструктор (В случае с "Или" - константу)Отслеживать чтоб, Кол-во конструкторов было равно кол-ву драйверов (В случае с "Или" - константы)Появится дополнительная зависимость от класса посредника CacheProvide
С другой стороны, можно написать интерфейс и имплементировать его непосредственно в классах RedisCache, FileCach
Использование:$cache = new RedisCache(array $cfg);В этом методе пока не вижу минусов. Если они все же есть, откройте мне глаза. Гуглил Interface vs Provider Но внятного не нашел.

Предыдущий
вопрос Следующий
вопрос

Интерфейс и провайдер - это два различных подхода к реализации функционала для нескольких движков кэширования.

При использовании провайдера (CacheProvider) вы создаете абстрактный класс, который описывает общие методы для кэширования, а затем реализуете эти методы в конкретных классах (например, RedisCache, FileCache). Провайдер в данном случае выступает как посредник между вашим кодом и конкретными реализациями кэширования.

При использовании интерфейса вы создаете интерфейс, который описывает общие методы для кэширования, а затем каждый конкретный класс (RedisCache, FileCache) имплементирует этот интерфейс. Таким образом, вы можете создать различные реализации для каждого движка кэширования, не завися от посредника.

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

При использовании интерфейса, ваш код становится более простым и модульным, но вы также теряете некоторые возможности, которые предоставляет провайдер, такие как добавление дополнительных методов в общий интерфейс.

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