Это нормально, если у библиотеки есть побочные эффекты?

Question

Я занимаюсь разработкой некоторых библиотек Kotlin, и у меня возникают следующие концептуальные проблемы:

1. Первая библиотека основана на сканере пути к классам Spring и предназначена для использования в качестве расширения пружины, поэтому она использует ядро ​​пружины в качестве зависимости. Это нормально? Как потенциальный пользователь моей библиотеки будет обрабатывать разные весенние версии?

2. Вторая библиотека основана на первой и предназначена для использования в p2p-сетях. Он синхронизируется с другими одноранговыми узлами и предоставляет общее состояние, которое может быть легко восстановлено пользователем библиотеки с помощью специального предварительно определенного сервиса Spring. Это нормально для библиотеки, чтобы иметь побочный эффект, как это? Может быть, есть какие-то шаблоны для реализации / распространения таких библиотек?

Если это не так, подскажите, пожалуйста, как это сделать правильно. Заранее спасибо.

Answer 1

Это немного общий вопрос, и наличие конкретных примеров поможет понять, нормально ли это делать или нет.

Но, вообще говоря:

1. Хорошо, если ваша библиотека зависит от других библиотек определенных версий. Большинство библиотек делают. Вопрос в том, насколько тяжелой и навязчивой является эта библиотека. И, к сожалению для вас, библиотеки Spring, как известно, оба. В случае конечного пользователя вашей библиотеки, в случае конфликтов ему просто придется выбрать, хочет ли он обновить версию Spring для вашей библиотеки или нет
2. Наличие некоторого распределенного состояния не обязательно является побочным эффектом. EhCache - это, например, библиотека распределенного кэша. Основной шаблон должен быть как можно более твердым. Когда я разработал кеширование для библиотеки Vert.x WebClient , я сделал так, чтобы он полагался на интерфейсы, а не на твердую реализацию, поэтому, если кто-то решит, что он не хочет использовать вашу библиотеку (например, компонент Spring), он может предоставить альтернативное решение.

Опять же, это основные рекомендации, не видя ваш код. Если вы намереваетесь открыть его исходный код, не стесняйтесь делиться конкретными битами, чтобы получить более конкретную информацию от сообщества StackOverflow.