Guice обнаруживает неиспользованные привязки - PullRequest
1 голос
/ 19 марта 2019

Я просто унаследовал большую кодовую базу. Я убираю и пытаюсь удалить ненужные зависимости.

Есть ли способ найти ненужные зависимости, определенные в инжекторе?

1 Ответ

2 голосов
/ 20 марта 2019

Вы можете использовать Elements SPI , который позволяет вам проходить привязки Guice в работающем инжекторе.Помните, однако, что Guice рефлексивно оценивает ваше дерево во время выполнения.Это позволяет вам добавлять привязки и зависеть от привязок JIT (Just-In-Time), но также делает это так, что Guice может даже не знать о классах, от которых вы не зависите через ваш инжектор.

ВПри патологическом случае у вас не может быть никаких модулей, определенных и зависящих от всего через привязки JIT, после чего любой неиспользуемый детектор привязки будет возвращать нулевой набор (ложные отрицания).И наоборот, если вы интенсивно используете getInstance или связанные методы Injector, но не выполняете их перед сканированием на предмет неиспользованных deps, вы можете вернуть много зависимостей, которые оказались небезопасными для удаления (ложные срабатывания).Это особенно верно, потому что Injector является инъекционным, поэтому, если у вас есть адаптер для устаревшего сервисного локатора (и т. Д.), Вам может быть трудно предвидеть все способы использования вашего Injector.

Чтобы избежать неожиданностей,Вы можете позвонить requireExplicitBindings(), что относится ко всему Инжектору и его детям, но не к его родителям или братьям и сестрам.Это может привести к необходимости определения всех привязок JIT, даже если только через нецелевое связывание .Вы также можете сканировать вызовы getInstance, getProvider и getMembersInjector и injectMembers на Injector и сокращать их с помощью рефакторинга.

Похоже, что существующее решение общедоступно в bonifaido'sguice-unused github tree , который позволяет избежать некоторых из перечисленных выше проблем путем явного запроса корневых запросов на привязку и повторного использования встроенного в Guice переходного посетителя графического адаптера зависимостей. Отказ от ответственности: Это не мой код.Это достаточно просто, но я не могу гарантировать ни его безопасность, ни статус его интеллектуальной собственности.

...