Каков наилучший подход для внедрения зависимостей, если Spring или Guice не используются?
Если ваша библиотека была написана в DI-дружественной идиоме. Это должно быть довольно легко использовать в качестве прямого API Java. Подумайте о своем прошлом опыте с весной. Есть несколько библиотек, которые идеально подходят к весенней модели, но были написаны до весны. Я не вижу ничего плохого в том, что new
сопровождается парой setXX
, за которыми следует вызов метода real work . Просто будьте особенно осторожны, так как, помимо прочего, ваш клиент может забыть вызывать эти init
методы, которые надежно вызывают.
Должен ли я рассмотреть что-то вроде фабричного метода для создания экземпляров и связывания объектов? Все зависимости находятся внутри библиотеки, поэтому не представляется целесообразным, чтобы приложение создавало каждую зависимость для создания главного объекта.
Пусть клиентское приложение решит это. Вы предоставляете библиотеку. Пусть клиент API связывает свои собственные объекты. Приведите пример. Позже этот же пример можно использовать для создания метода фабрики в домене клиента. Возможно, клиентское приложение имеет свой собственный способ настройки, и было бы желательно, чтобы API, предоставляемый вашей библиотекой, был достаточно гибким, чтобы воспользоваться этим.
Или, может быть, вы можете включить хитрость. Лицензия Apache. Так же, как целый кусок самой Java.