Желая распространять программу как фреймворк, но беспокоюсь о количестве зависимостей

Question

У меня есть проект, который сейчас находится между строкой фреймворка и подключаемой программы, и меня беспокоит огромное количество зависимостей, на которые опирается эта программа.

В настоящее время у меня есть это:

• Commons lang - В основном для строковых утилит и массивов
• slf4j - Лесозаготовительный фасад
• slf4j-log4j - Перенаправляет запись в log4j для GUI (обратите внимание, что GUI является модулем)
• log4j - сам Log4j по вышеуказанной причине
• jpersist / EJP - Уровень абстракции базы данных
• PircBot - слой IRC
• Драйвер JDBC
• Mozilla Rhino - для плагинов Javascript

Всего 7, даже без графического интерфейса, если только вы не хотите вести журнал. Для меня, который пытается выдать это за «легкий», это кажется слишком много.

Итак, мои вопросы:

1. Стоит ли ограничивать количество используемых фреймворков?
2. Как мне его раздать? Хорошо ли будет использовать независимую банку для использования в других программах и большую комбинированную банку для одной программы?
3. Нормально ли это много зависимостей?

Answer 1

Должен ли я ограничить количество фреймворков, которые я использую?

Если вы действительно используете / нуждаетесь в них, не совсем.Я бы просто попытался избежать наложения библиотек и добавления библиотеки, если вы используете только 1% от нее.

Как мне ее распространять?Хорошо ли будет использовать независимый jar для использования в других программах и большой комбинированный jar для одной программы?

Многие проекты распространяются в виде дистрибутива zip / tar.gz.Но для фреймворка, сделать его доступным как артефакт Maven было бы большим плюсом (в этом случае, сделайте log4j и привязку log4j optional).

Это много зависимостей нормально?*

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

Answer 2

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

Можете ли вы указать независимые от реализации библиотеки?например, commons-logging , который делегирует существующие каркасы ведения журналов под крышками.Если ваши пользователи уже используют что-то отличное от log4j, то это позволит им продолжать работу без необходимости переключаться.

Во-вторых, ваша инфраструктура делает слишком много?Вместо обеспечения реализации чата, почему бы не предоставить подходящий API, чтобы клиенты могли подключить свой собственный механизм чата / уведомлений.Таким образом, ваша структура становится более общей, и (опять же) ваши клиенты могут выбирать, какие / как реализовать функции.Богатый клиентский API предоставит вашим пользователям гораздо больше возможностей и расширит возможности вашей инфраструктуры.

Answer 3

масштаб вашего проекта, т.е. то, что он выполняет и в какой среде он будет использоваться, будет сбалансирован с количеством зависимостей и простотой настройки в целом, когда люди оценят пригодность вашего проекта.

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

единственное, что звонит в тревогу - это уровень базы данных и драйвер jdbc. если ваш проект является «фреймворком», я не вижу, как конкретный драйвер jdbc соответствует модели, а постоянство в целом не совсем соответствует модели фреймворка.

Answer 4

Думаю, вы сильно переживаете :) Количество зависимостей не актуально, зрелость у них есть. Если вы отбросите функциональность / удобство использования / гибкость / и т. Д. Только потому, что хотите сохранить количество зависимостей на «низком уровне», это будет потерей для вас (и ваших клиентов).

Answer 5

Это может показаться как множество зависимостей, но я не думаю, что это на самом деле.Конечно, кажется, что нет большого количества бесполезного дублирования функциональности.Большинство зависимостей делают то, что в противном случае вам нужно было бы реализовать самостоятельно.

Для меня, кто пытается выдать это за «легковесное», это кажется слишком много.

Может быть, вам нужно скорректировать свою риторику.: -)

Серьезно, если эти зависимости необходимы, единственный способ избавиться от них - это либо самостоятельно кодировать эквивалентную функциональность (плохая идея), либо отказаться от соответствующей функциональности (возможно, плохая идея).).Что для вас важнее;быть легким или функциональным?

РЕДАКТИРОВАТЬ

Функциональным является ключ в конце.У меня может быть своя собственная реализация всего, но я думаю, она будет полна ошибок.Тем не менее, я бы хотел, чтобы он был маленьким, а маленький и простым - привлекал людей.Решение за вами.(Но не забывайте, что в то время как одних людей откладывает «раздувание», других привлекает множество функций.)

Я полагаю, что есть промежуточное решение.Сохраните функциональность, но сделайте ее необязательной и предоставьте пользователям возможность настраивать ее как вход, так и выход.Конечно, недостатком является то, что это означает, что вам необходимо протестировать несколько вариантов конфигурации, и это усложняет установку / настройку для ваших пользователей.