Дизайн программного обеспечения: разделение при сильной зависимости от сторонней библиотеки
что сцепление - это плохо и его следует избегать по мере возможности
Я думаю, что это слишком догматично.
В некоторых случаях имеет смысл просто смириться с тесной связью. Это особенно верно, если вы пишете код, который, как ожидается, не проживет долго.
В других случаях вы можете захотеть добавить уровень абстракции. Идея заключается в том, чтобы создать интерфейсы, представляющие необходимую функциональность, и реализовать их с помощью вашей библиотеки.
очень распространенной проблемой при таком подходе является утечка абстракций. Есть большая вероятность, что ваши интерфейсы будут очень похожи на библиотеку, от которой вы пытаетесь отделиться. И это, скорее всего, не позволит легко заменить библиотеку.
хорошо спроектированные интерфейсы, чтобы их можно было использовать с несколькими различными библиотеками, очень сложно, по крайней мере, для более сложных библиотек с большими API. Поэтому я бы рассмотрел вашу фактическую цель. Нужно ли облегчить тестирование? Или позволить заменить плагин на другую библиотеку?
Вы также можете рассмотреть риск, связанный с любой зависимостью. Является ли она с открытым исходным кодом? Есть ли у него активное сообщество? Можете ли вы самостоятельно исправить ошибку, если это необходимо? Есть ли возможные замены? Насколько сложной будет замена? Если это коммерческий продукт, является ли компания стабильной? Какие у них есть гарантии поддержки? Совместима ли лицензия с тем, что вы хотите делать?
рекомендации в интернете могут быть полезны, важно понимать, какую проблему они пытаются решить и когда они применимы.
Прикрепляю к посту несколько видео по теме: