CacheProvider, какими стандартами и практиками пользоваться при написании на php?

Question

[thorii]

CacheProvider, какими стандартами и практиками пользоваться при написании на php?
Собственно я задумал кэшпровайдер лишь как класс единого API кэширования, но стал вопрос, как указывать драйвер для работы с кэшем?

На текущий момент у меня так:

<?php
$cache = new CacheProvider(CacheProvider::DRIVER_REDIS, $configRedis);
$cache->set('key', 'value');
?>

Вопрос в следующем: Критично ли использование констант для идентификации драйвера? То есть в самом классе прописаны константы идентификации:

const DRIVER_REDIS = 0;
const DRIVER_MEMCADHED = 1;
const DRIVER_FILE = 2;

По этим ID в конструкторе из конфига грузится путь класса драйвера и создание его экземпляра:
Cache.Config.php

<?php
$config = array(
	'drivers' => array(
		'0' => array(
			'name' => 'RedisDriver',
			'lib' => '\Architect\Cache\Drivers\RedisDriver'
		),
		'1' => array(
			'name' => 'MemcachedDriver',
			'lib' => '\Architect\Cache\Drivers\FileDriver'
		),
		'2' => array(
			'name' => 'FileDriver',
			'lib' => '\Architect\Cache\Drivers\FileDriver'
		)
	)
);
?>

При добавлении драйверов приходится прописывать константу идентификации. Может переписать на именованном конструкторе?

$cache = CacheProvider::driver('REDIS');
$cache->set('key', 'value');

Или меня просто параноит за зря и мне надо избавиться от констант и прописывать строкой имя драйвера?

$cache = new CacheProvider('REDIS', $driverConfig);

P.S. Очень трепетно отношусь к мелочам.
-Подсмотреть Доктрину/Symfony/Laravel/YII/CI не предлагайте пожалуйста.

Используется ли в таких случаях именованный конструктор?

Comments

[Алексей Скобкин]

Можно посмотреть на PSR-6: www.php-fig.org/psr

Answer 1

[Andrey Kulikovsky]

Лучше создаввать конкретный экземпляр класса, вида RedisCacheProvider реализующий общий интерфейс, наприер CacheProviderInterface.
Подсмотреть можно здесь: https://github.com/doctrine/cache

Также, создание объектов я бы вынес в DI-контейнер. И почитайте про инверсию зависимостей (если нужно).

Comments

[thorii]

Если бы знал что все подсели на Doctrine как на героин, дополнил бы, чтоб не предлагали подсмотреть там (Одна строчка у меня = 10 классов доктрины). Я эту доктрину уже месяц переварить пытаюсь.

+ Мне не нужны лишние слои абстракции Я не фреймворк пишу.
+ Интерфейсы тоже не нужны, не вижу смысла плодить их стандарта ради. Опять же, я не фреймворк пишу (Да да, я уверен что смогу разобраться в коде спустя месяц/год/век)

В ответе на вопрос я хотел узнать способы эстетичного оформления кода, то есть, что является плохим тоном, а что сойдет! Для себя, доктрину я считаю ужасной, слишком много слоев абстракции на мой счет. (Может автор любит Ctrl+N).

Насчет RedisCacheProvider: У меня итак есть DriverRedis, полностью описывающий методы CacheProvider(Это некий слой абстракции). Для моих нужд хватает использование глобального провайдера. Вопрос как элегантнее реализовать поддержку множества драйверов, чтобы в будущем не было путаницы, связанной с редактированием кода CacheProvider при добавлении нового драйвера

Кстати, поясните, зачем в Доктрине для вывода версии ОТДЕЛЬНЫЙ КЛАСС? Это мода такая? на каждую строку плодить классы?

[Andrey Kulikovsky]

Можно включить только это библиотеку доктрины, только кэш. Вся доктрина не нужна.
Вообще, я придерживаюсь идеи, что явное лучше не явного.

В общем, я бы тогда в этом случает сделал фабрику, которая возвращала уже готовый экземпляр, а параметр, какой имено провайдер, через константу. Название констант сделал бы строковые:

const DRIVER_REDIS = 'redis';

В сервисах/контроллерах/итд внедрял бы кэш-провайдер как зависимость. Таким образом:

class MyService{
public function __construct(CacheProviderInterface $cache) {
$this->cache = $cache;
//...
}
}

[thorii]

Andrey Kulikovsky: Уже ближе к истине. Спасибо!