Организовать мелкие коммунальные функции

Question

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

У меня есть целая коллекция этих функций. Интересно, как вы, ребята, организовываете их? Есть ли у вас какие-либо советы?

Вот как я это делаю. Я поместил его в отдельный проект (проект eclipse), скажем, «MyUtils», и на него ссылаются другие проекты. Это работает, но так как коллекция утилит становится все больше и больше, странно, что утилиты больше, чем код проекта (для небольших проектов). И чтобы отправить его в Jar, вы должны выбрать их все вручную (или включить все). Есть ли лучший способ?

Кроме того, поскольку Java требует, чтобы все функции были в классе, у меня есть тонна статических функций (тех, которые не вписываются в ООП), например, функция чтения текстового файла из имени файла. Как это:

 package nawaman.myutil;

public class UText {

    static public String ReadTextFile(String pFileName) {
        ...
    }
    static public String[] ReadLines_fromFile(String pFileName) {
        ...
    }
    static public String ReadLine_fromFile(String pFileName, int pLineNumber) {
        ...
    }
    ...
}

Так что, когда мне нужно включить все функции, идет, хотя он не используется.

Есть ли лучший способ сделать это?

В любом случае, я использую eclipse в Linux, если для него есть специальная техника, но вы можете поделиться им, если у вас есть методы с другими инструментами.

Answer 1

Вы должны быть очень осторожны с удалением классов после компиляции - вы можете оказаться в ситуации, когда класс не найден во время выполнения. Если вы никогда не используете отражение или Class.forName (), вы должны быть в безопасности, но они вводят зависимости во время выполнения, с которыми компилятор не может вам помочь (как это может быть с «новым»).

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

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

Answer 2

Разделите ваш модуль утилит на более мелкие подпроекты. Используйте Maven или другую систему сборки для отслеживания версий всех ваших утилитных модулей. Они имеют решающее значение для ваших систем, потому что я думаю, что они используются почти во всех ваших проектах. Используйте такие инструменты, как Findbugs или PMD , чтобы убедиться в качестве вашего кода.

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

Пожалуйста, пересмотрите ваши классы с другими проектами общего достояния, такими как Apache Commons . Я предполагаю, что большая часть вашего служебного кода похожа. Подумайте лучше о переписывании ваших статических методов , потому что они мешают тестированию (я уверен, что Findbugs тоже будет много жаловаться).

Подводя итог - создание библиотеки утилит - сложная задача и много ответственности. Так что требования в области качества кода очень высоки. Я надеюсь, что мой совет поможет.

Answer 3

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

• Для каждого компонента я создаю проект Eclipse и собираю его в банку.
• Классы логически сгруппированы в пакеты, например, [домен] .util.net, [домен] .util.text и т. д.
• В проект я включаю зависимости, которые мне нужны. Maven может помочь вам здесь.

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

Answer 4

Мои "утилиты" имеют свое собственное пространство имен пакетов и репозиторий SVN. Они, по сути, мои собственные библиотеки: отдельные проекты, которые можно загружать, совместно использовать, маркировать, обновлять , что угодно.

Организация, используемая в каждой из этих "библиотек", зависит от области применения и функции.

Поскольку я не согласен со структурой, являющейся подчиненной некоторому потенциальному выходу класса / JAR: Если вы беспокоитесь о «методе раздувания» в классах и / или JAR, пожалуйста, используйте автоматизированный инструмент для борьбы с этим. ProGuards - всего лишь один пример , и, хотя он может запутывать, он может одинаково хорошо работать только при «удалении мертвого кода».

Answer 5

Это работает, но поскольку коллекция утилит становится все больше и больше, странно, что утилиты больше, чем код проекта (для небольших проектов). И чтобы отправить его в Jar, вы должны выбрать их все вручную (или включить все). Есть ли лучший способ?

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

Кроме того, поскольку Java требует, чтобы все функции были в классе, у меня есть тонна статических функций (тех, которые не вписываются в ООП), например, функция чтения текстового файла из имени файла.

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

Answer 6

Я не использую Eclipse, но в Visual Studio вы можете добавить ссылку на файл без его физического перемещения или копирования. Это позволяет вам определить файл в корне вашего исходного контроля, на который могут ссылаться все ваши проекты, без включения его в каждый проект или необходимости решения проблемы копирования. С помощью такого решения вы можете разумно разделить ваши утилитарные методы на разные файлы и выборочно включать их в зависимости от потребностей отдельных проектов. Также вы можете избавиться от лишнего .jar.

Тем не менее, я понятия не имею, поддерживает ли Eclipse этот тип ссылок на файлы, но, возможно, стоит посмотреть.