sda писал(а): ↑2017.09.12, 22:32
ElisDN ваши сервисы зависят от интерфейсов внешних компонентов/библиотек ? Что делать если надо заменить текущую библиотеку на библиотеку с другим интерфейсом ? Придется исправлять код сервисов или писать адаптер на чужой интерфейс. Зачем это делать если можно написать адаптер сразу и под свой интерфейс какой нужен в вашем приложении ?
Сервисы не зависят. А репозитории и эти самые адаптеры в инфраструктуре как раз зависят напрямую от фреймворковских Connection, Logger и внешних библиотек.
Из статьи Вы процитировали:
У половины стандартных компонентов нет интерфейсов что бы прокинуть в класс.
Речь именно о сложностях прокидывания в конструкторы встроенных компонентов фреймворка. Что надо костыльно извратиться, чтобы компоненты из ServiceLocator прокинуть назад в Container. Хотя это лишь эстетическое неудобство, вызванное одновременным присутствием этих двух вещей вместо одного.
sda писал(а): ↑2017.09.12, 22:32
Верно. Напишите свой интерфейс + реализующий его адаптер и используйте внутри адаптера хоть yii-шный кеш хоть какой другой.
Я написал свой адаптер и получил геморрой с DIC, когда понадобилось прокинуть в него Connection. Проблема решилась переносом всех компонентов в контейнер. Речь опять об этом.
sda писал(а): ↑2017.09.12, 22:32
Зачем вам надо чтобы в самом yii сделали интерфейс ?
Библиотеку можно легко выкинуть или поменять, сменив адаптер под свой интерфейс. Фреймворк с ней никак не связан и проблем с этим нет. Другое дело - компоненты, встроенные в сам фреймворк.
Мне здесь постоянно говорят, что Yii - гибкий фреймворк, не навязывающий никакую архитектуру, который я могу легко кастомизировать и расширять под свои нужды. Что я просто не умею его "готовить".
И вот я, вдохновившись этим и бросив себе вызов, захотел задекорировать UrlManager гибким и расширяемым путём без наследования:
Код: Выделить всё
return new LanguageUrlManager(
new CityUrlManager(
new CacheUrlManager(
new UrlManager($app->params['urlManager']),
$container->get(Cache::class)
),
$container->get(CityRepository::class)
),
$app->params['languages']
)
и выложить каждый декоратор на GitHub. А здесь такой "облом", что UrlManagerInterface нет и вместо чистого implements UrlManagerInterface мне придётся в каждом классе делать extends UrlManager с кучей ненужных мне public-полей... И вдохновение прошло.
И так любое чистое декорирование/проксирование/адаптирование внутренностей для доработки или подмены пролетает с адским свистом костылей. Ну не захотели разработчики упростить кастомизацию для опытных программистов, побоявшись распугать "непонятными интерфейсами" всех новичков, у которых один только IdentityInterface вызывает дикий ужас.
sda писал(а): ↑2017.09.12, 22:32
Верно. Напишите свой интерфейс + реализующий его адаптер и используйте внутри адаптера хоть yii-шный кеш хоть какой другой. Зачем вам надо чтобы в самом yii сделали интерфейс ? Вы у каждой библиотеки будете просить интерфейс ?
Свои внешние адаптеры я напишу. Речь про внутреннее хардкорное отсутствие интерфейсов у встроенных компонентов фреймворка.
sda писал(а): ↑2017.09.12, 22:32
Кеш пример.
Как уже видим, у фреймворка захардкожено куча кода. Без разделения по ответственностям на внутренние сервисы, адаптеры, резолверы и прочее. В итоге подменяется всё либо через наследование, либо целиком файлами с копипастой через $classMap.
sda писал(а): ↑2017.09.12, 22:32
PHP не мир. PSR не стандарт.
Это только в Yii-мире PHP - не мир, а PSR - не стандарт.