Является ли наличие в классе только одного класса запахом кода?

Question

Плохо ли иметь пакет с одним классом?Будет ли более разумным просто переместить отдельный класс в пакет util, который будет содержать другие случайные полезные классы?

Answer 1

Плохо ли иметь пакет с одним классом?

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

Примером последнего может быть тот, где у вас есть общий API, и несколько реализаций этого API, где каждая из реализаций состоит из нескольких классов.Но одна из этих реализаций (назовем это реализацией Null) состоит только из одного класса.

Реальный тест состоит в том, служит ли структура пакета своей цели:

• Облегчает ли поиск библиотечных классов?

• Упорядочивают ли пакеты классы приложения в соответствии со структурой логического модуля приложения?

• Позволяет ли структура эффективно использовать видимость "пакета частной"?

Будет ли более разумным просто перенести отдельный класс в пакет утилитчто бы содержать другие случайные полезные классы?

Не обязательно.Если класс является просто еще одним «случайно полезным» листовым классом, то есть хороший повод для его перемещения.С другой стороны, если он имеет определенную функцию и не предназначен для общего использования, то лучше оставить его там, где он есть.

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

Answer 2

Плохо ли иметь пакет с одним классом?

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

Разумнее ли было бы просто переместить отдельный класс в пакет util, содержащий другие случайные полезные классы?:

1. Util имеет особое значение.Перемещение произвольного объекта в util по причинам одиночества было бы пограничным случаем злоупотребления служебным положением.
2. Это преждевременная организация.С Java поддержка IDE достаточно богата, чтобы легко и эффективно реорганизовать ее несколькими щелчками мыши.Подождите некоторое время, чтобы увидеть, как ваш проект развивается, а затем принять вызов.

Answer 3

Нет

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

Answer 4

Существуют различные состояния для статических утилит.Я использую это:

• , если ваш класс util является универсальным (утилиты String, утилиты DB и т. Д.), Я помещаю его в пакет «util», который используется во всех приложениях.1004 *
• если класс util специфичен для домена, я условно называю его «DomainHelper» и помещаю в пакет домена на том же уровне, что и классы домена.

Answer 5

Да , это определенный запах кода.

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

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

Пакеты должны реализовывать функции. Редко когда функция реализована с использованием только одного класса.

Answer 6

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

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

Answer 7

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