Нужно ли при разработке библиотеки следовать принципу одной ответственности?

Question

[Андрей К]

В отношении библиотеки его можно было бы назвать "принцип однослойности задачи"...
Можно скрыть в библиотечном методе много сложной логики. При этом уровень инкапсуляции вырастет, уменьшится сложность кода основной программы, что хорошо. С другой стороны, увеличится сложность библиотеки. А ещё она станет тянуть за собой дополнительную зависимость, версия которой часто будет не совпадать с версией такой же библиотеки в основном приложении, увеличивая тем самым его размер.
Казалось бы, ответ очевиден: не нужно "тянуть" в библиотеку много зависимостей ради удобства. Но я регулярно наблюдаю это у библиотек, с которыми работаю: все всё тянут.
Как поступать правильно?
p.s. Если это имеет значение, пишу код для Android.

Answer 1

[Сергей Соловьев]

Это скорее проблема версионирования, чем SRP
Я бы дал такой ответ: тяните что хотите.
Почему:
- Пользователи могут начать использовать вашу версию зависимости - просто откатиться от своей
- Вы можете выложить новую версию своей библиотеки с обновленными зависимостями
- Увеличение продуктивности разработки: скорость, удобство

В любом случае, если им жизненна необходима ваша библиотека, то будьте уверены - они найдут способ ее к себе притащить. Доходя до прямого копипаста исходников

P.S. Как я понял, вы думаете, что увеличение уровня абстракции метода влечет за собой обязательное использование внешних зависимостей, то это не обязательно так - все пишут велосипеды. Например, я однажды написал минималистичный парсер JS, вместо использования сторонних библиотек. Сложность по факту одна и та же, но зависимостей нет.

Answer 2

[mayton2019]

Да можно. Это называется фасадом. Ограничение в single responsibility обычно относится к ООП и к классам.

Вообще если ты фрилансер и делаешь просто заказ чтоб отдать его с концами - то тебе безразлично что будет внутри. Главное чтоб ты понимал. А соглашения по декомпозиции кода на части появляются только как результат
коллективной работы над кодом. Тоесть ты должен спрашивать не qna, а свою команду как вам удобнее
разрабатывать код.