Пользовательский пакет утилит Java

Question

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

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

Я понимаю, что это, вероятно, признак того, что я должен переосмыслить организацию проекта, но есть ли что-нибудь вредное в добавлении пакета для хранения служебных функций всего проекта? Есть ли стандартный способ справиться с этой ситуацией в Java?

Answer 1

Это общая проблема, а не только Java.

"Так как это казалось вредным" - в чем вред? Связь? Единственная точка отказа?

У вас есть пример того, что вы сделали в самом JDK: java.util имеет множество классов, которые используются повсеместно.

Я думаю, что ваш дизайн оправдан. Продолжайте в том же духе, пока опыт не покажет вам лучшее место для этого класса.

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

Answer 2

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

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

Answer 3

Есть ли что-нибудь вредное в добавлении пакета для хранения утилит всего проекта?

Не совсем.Пакеты утилит существуют для хранения классов утилит.

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

Answer 4

Лично я бы сделал нечто похожее на то, что вы сделали. Я обычно создаю пакет util в базовом пакете для общих служебных функций проекта, которые, как я знаю, будут использоваться в моем проекте.

Если мне нужна служебная функция, которая используется только определенным классом, сам класс может справиться с этим. Если мне нужна утилита, которая будет использоваться классами в определенном пакете, создайте пакет util в этом.

Только мои два цента.

Answer 5

Я просто хотел бы добавить «высокий фан-ин» в качестве термина для таких служебных классов.От Code Complete (2nd Ed.) , ссылаясь на него как на одну из нескольких «желательных характеристик дизайна»:

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

Answer 6

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

Answer 7

служебный класс - это класс, который определяет набор методов, которые выполняют общие, часто повторно используемые функции. Большинство служебных классов определяют эти общие методы в статической области видимости. Примеры служебных классов включают java.util.Collections, который предоставляет несколько служебных методов (таких как сортировка) для объектов, которые реализуют коллекцию. Служебные классы всегда должны быть окончательными и иметь закрытый конструктор.