Семантически более подходящее имя пакета, чем `util` для следующих вещей?

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

В качестве одного примера, возьмем класс, UUIDкаким было бы семантически правильное имя пакета для этого класса?

Я работаю над реализацией своего собственного UUIDкласса, чтобы быть более легким. Я не хочу использовать me.myproject.util.UUIDдля моего имени пакета.

Я считал, me.myproject.rfc4122.UUIDно это не подразумевает семантику использования UUID.

Я также рассмотрел, me.myproject.uuid.UUIDно я не люблю тавтологию в этом, даже несмотря на то, что в Python является популярным подходом помещать класс в модуль с тем же именем, а packagesв Java не являются семантически эквивалентными modulesв Python.

Я также рассмотрел, me.myproject.UUIDно отклонил это, потому что я не хочу загрязнять эту часть пространства имен вещами, которые не связаны. Это просто поднимает проблему на новый уровень.

Я также подумал, me.myproject.lib.UUIDно это не имеет более смыслового значения, чем .utilпросто переименовывает проблему.

semantics: отрасль лингвистики и логики, связанная со смыслом .

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

Более прагматичный подход к именованию пакетов - просто помочь вам найти материал. Хранение часто используемых вещей, которые вы всегда знаете, где найти все в одном месте, мешает им в пути и, следовательно, облегчает поиск более редко используемых вещей. Таким образом, вам на самом деле не нужны имена пакетов, которые семантически правильны для каждого из классов, которые они содержат, вам просто нужны имена пакетов, которые не являются семантически некорректными. Очевидно, что «Util» имя пакета был выбран в соответствии с этой линии мышления: не семантически правильное название для классов , которые он содержит, но это также не семантически неверно, и это достаточно хорошо.

Итак, если ваш тип UUID предназначен для использования только этим конкретным приложением (о чем свидетельствует тот факт, что вы планируете поместить его в «myproject»), то он, вероятно, является частью «модели» вашего проект. У вас уже должен быть пакет 'model', содержащий набор всех классов, которые соответствуют вашим постоянным объектам, многие из которых, вероятно, имеют отношения между ними, причем UUID, вероятно, являются средством реализации этих отношений. Кроме того, ваши UUID, вероятно, знают, как сохранить себя, верно? Кроме того, ваши UUID, вероятно, могут быть найдены только как члены вашей модели сущностей, верно? Таким образом, ваша модель пакета, вероятно, лучшее место для этого.

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

Назначение пакетов - группировать классы в соответствии с некоторыми критериями (пакет по типу / слою, пакет по элементу и т. Д.). Я не вижу смысла создавать пакет только для одного класса, особенно если вы не ожидаете, что в будущем в этом пакете будут другие классы.

Также я думаю, что имя пакета «util» не является полностью бессмысленным - оно просто группирует классы по определенным критериям - для меня класс «util» означает, что оно не является частью домена приложения, но оно также не является частью фреймворк (не влияет на структуру приложения). По сути, это просто расширение (не) стандартной библиотеки.

В этом случае у меня не было бы проблемы с помещением этого класса UUID в пакет «util». Если будут некоторые другие связанные с UUID служебные классы (например, отдельный класс для генерации UUID), то для них будет легко провести рефакторинг и создать пакет «util.uuid» (если только вы не создаете библиотеку, и UUID будет частью открытого интерфейса). тогда нужно быть немного «дальновидным»).

У дяди Боба есть некоторые рекомендации по разделению пакетов.

Первые три принципа пакета касаются сплоченности пакета, они говорят нам, что поместить в пакеты:

1. Гранула повторного использования - гранула выпуска
2. Классы, которые изменяются вместе, упакованы вместе
3. Классы, которые используются вместе, упакованы вместе

Итак, отвечая на ваш вопрос, кто / что собирается использовать класс UUID, использовать его в качестве атрибута или вызывать в нем операции? Как твой график зависимости ? UUID будет использоваться вместе с какими другими классами ?

В зависимости от вашего ответа, может быть , вы должны назвать это me.myproject.identity пакет, me.myproject.serialization пакет, me.myproject. DTO или даже что-то еще полностью. Возможно, класс UUID должен храниться вместе с вашими моделями, и вы поместите его в пакет, который у вас уже есть, например, me.myproject.models .

Прежде всего, UUID (с заглавными буквами) кажется мне очень плохой идеей для имени пакета или имени класса, так как все стили, применяемые так или иначе, все имена в верхнем регистре связаны с «константами». Пакеты предназначены для упорядочивания вещей, самый простой способ назвать пакет по значению классов, которые он содержит:

• например, вы можете разделить классы по их стоимости com.example.identifier;
• или по их технической ценности, например com.example.uuid.

Сделайте это простым