Чи повинна моя маленька бібліотека програмного забезпечення уникати використання інших бібліотек?

Щойно я випустив невелику бібліотеку Java, яка пропонує лише кілька класів та методів. Оскільки я створив проект разом з Maven, я негайно використав декілька сторонніх бібліотек для досягнення своїх цілей, зокрема:

commons-lang3 (для деяких загальних речей Java)
slf4j-api (для лісозаготівлі)
commons-io (для крихітного файлу - буквально один раз читаю файл, я думаю)

Я не хочу, щоб моя бібліотека виглядала роздутою в очах інших. Чи слід намагатися усунути свою залежність від цих бібліотек, щоб мінімізувати слід? Будь-яка порада про те, яких типів бібліотек найкраще уникати, коли планується використовувати більше в майбутньому?

java libraries maven

— Дункан Джонс
джерело

конкретна частина вашого питання виглядає відповідальною: ваш проект плюс бетонні зв'язки плюс чи це добре. Проблема в тому, що ви написали це разом із загальною частиною "слід ... малим ... уникати". Наразі це запитання не підходить для нашого формату запитань. Ми очікуємо, що відповіді будуть підкріплені фактами, посиланнями або конкретною експертизою, але це питання, ймовірно, вимагатиме дискусій, аргументів, опитування чи розширеного обговорення. Якщо ви вважаєте, що це питання можна вдосконалити, перегляньте відповіді на поширені запитання .

— гнат

@gnat Мої вибачення Як звичайний користувач із переповненням стека, я схилявся до того, що злегка суб'єктивні питання прийнятні для програмістів. Чи є сайт Stack Exchange, на якому такі проблеми добре? Тим часом я усуну будь-яку нечіткість із мого запитання.

— Дункан Джонс

@gnat Це питання чудово, навіть у первісному вигляді.

— Томас Оуенс

@ThomasOwens з усією повагою, я не думаю, що так; для оригінальної версії я швидко розібрався у двох відповідях із протилежними рекомендаціями, обидва обґрунтовано обґрунтовані: гра з голосуванням для голосування

— gnat

@gnat Тільки два? Це чудово. Нехай вони будуть розміщені та проголосовані. Дві потенційно правильні відповіді з обґрунтуванням та аргументацією, які протилежні, не роблять питання поганим. Ні 3, ні 4, ні навіть 5. Це добре сформоване питання, з яким повинні вирішуватись розробники проблемних бібліотек, а на них відповідати тягар, щоб вони були хорошими відповідями .

— Томас Оуенс

Відповіді:

Я відповідаю на це, враховуючи вашу конкретну ситуацію. Я б сказав, що ці бібліотеки добре використовувати. Просто переконайтеся, що ваш slf4j-api не підтримує реалізацію. Під цим я маю на увазі позначити залежність реалізації як "тест". EG:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.2</version>
    <scope>test</scope>
</dependency>

Це докладно описано у поширених питаннях SLF4j.

Що стосується двох інших, IME, вони завжди сумісні назад. Тому, якщо через 5 років мені потрібно використовувати вашу бібліотеку, але ви використовуєте стару версію, я можу просто виключити ваші залежності, і наш код все одно буде працювати. Іншими словами, використовуючи ці конкретні бібліотеки, ви не введете jar-hell для інших.

Якщо я користуюся вашою бібліотекою через maven, я не помічу, чи ваша бібліотека роздута чи ні. Я буду просто залежати від вашого і використовувати його. Я думаю, що важливіше, щоб ваш код працював правильно, ніж його менший слід. Я вважаю за краще використовувати commons-io замість того, щоб винаходити колесо з помилкою в ньому.

— Даніель Каплан
джерело

Дякую за відповідь, я думаю, що ми широко погоджуємось із підходом, який я повинен застосувати. Просто для виправлення одного біта - так, як слід включити slf4j до бібліотечного проекту, це просто включити slf4j-apiта не мати інших пов'язаних артефактів, наданих чи іншим чином. Дивіться slf4j.org/manual.html#projectDep .

— Дункан Джонс

Я пригадую деякі уражаючі мозку вправи (мільйони excludes iirc), які мені довелося робити, коли конкретні модулі в моїх залежностях не могли "погодитися" на версію slf4j. З вашої відповіді виглядає так, якби дизайнери модулів викрили б це provided, не було б таких питань, правда?

— гнат

@gnat Зазвичай це вирішиться (як мінімум у Maven), оголосивши одну бажану версію у вашому POM. Мейвен приймає "найближчу" версію, визначену для артефакту, і безпосередній POM переважає транзитивні залежності. Можливо, це було зміною поведінки під час випуску Maven 2.x.

— Дункан Джонс

+1 для визначення slf4j як provided- дуже ненав'язливий.

— Гері Роу

@DuncanJones дякую, я, мабуть, пропустив це ще тоді. Моя версія Maven була 2.2 або 2.3, не можу пригадати, яку з них (хоча я впевнений, пам'ятаю, як mvn dependency:analyzeприносили версії для лайна до моменту виключення :)

— gnat

Ні.

"Здуття" - це міф. Незалежно від того, скільки коду є у вашій бібліотеці, якщо якийсь із цього коду ніколи не буде використаний, він не буде застосовано на сторінку, він не матиме жодного впливу ні на продуктивність, ні на пам'ять.

З іншого боку, якщо вам потрібен додатковий функціонал, у вас є два варіанти. Ви можете написати це самостійно і витратити багато часу і зусиль на вирішення проблем, які вже вирішили інші, або ви можете скористатися рішенням, яке вже існує (і було протестовано / налагоджено / тощо).

Це залишає нам розмір завантаження та дисковий простір, і якщо ви не говорите про нерозумні цифри, у 2013 році це два фактори, які повинні бути близько до нижньої частини списку речей, про які потрібно турбуватися.

— Максим Мінімус
джерело