Ты получаешь кучу классов с неопределенным количеством зависимостей. В смысле, ты видишь класс, но конструктора нет, заюзать можно что угодно. Снижается читабельность, накладывается отпечаток на дизайн: ты меньше задумываешься о слоях, вот у тебя тут всё по рукой.
Когда ты используешь сервисы в entities/VO — это тоже проблема дизайна, усложняется как понимание кода, когда объект а-ля DateTime может лезть в базу, так и тестирование (ведь нужно что-то там мокать, в случае нормальных VO ты просто создаешь инстанс прямо в тестах).
Ты получаешь зависимость от этого трейта и SL. Ты получаешь проект «в себе», без возможности реиспользования. Ты можешь это парировать тем, что там, где нужна реюзабельность, ты не будешь использовать трейт, но ни ты, ни твои коллеги не знают где находится эта грань.
Для решения чисто технических проблем типа «два сервиса, один класс», тебе потребуется пилить костыли с переопеределением $container, менять код самого класса.
У тебя 100% будет куча конфликтов в большой команде, когда все побегут добавлять свои сервисы в @property в трейте. Со временем это превратиться в мусорку, не говоря про то, что это уже выглядит странно (dollar_rate? pdo? settings?):
PHP:
* @property \Monolog\Logger logger
* @property \Aura\SqlQuery\QueryFactory qbf
* @property \Aura\Sql\ExtendedPdo db
* @property \Slim\Collection $settings
* @property string $dollar_rate
Тут есть ещё одна проблема дизайна: \Slim\Collection $settings с первого взгляда — вполне нормальная зависимость, но дело в том, что часть сервисов действительно требует прямой зависимости от настроек проекта, а часть — через аргументы методов, т.к. сами значения могут прийти как из настроек, так и из другого источника (от админа, юзера, etc.). И здесь появляется соблазн везде использовать $settings, а потом перепиливать кучу классов, когда где-то потребуется другой источник данных. Аналогично со всякими getCurrentUser(), кстати. Появляется зависимость от конкретного контекста, т.к. сам подход провоцирует.
В конце концов, мы не роботы, а люди, есть чисто психологические моменты. Работать в проекте, который пронизан сомнительными практиками — это лишний стресс. Когда ты понимаешь, что ради сиюминутной выгоды, кто-то написал такой ущербный код, что для реализации простой с точки зрения менеджера задачи, тебе придётся изрядно потрудится, ты хочешь найти этого человека и объяснить ему кто он такой. Но такой человек обычно уже не работает в этом проекте. Он гуляет от проекта к проекту, щедро делясь своими архитектурными решениями, исследуя пределы возможного.
