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

18

Как соломенный эксперт, посчитайте, что пакет 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: отрасль лингвистики и логики, связанная со смыслом .


источник
Как насчет me.myproject.UUID? Илиme.UUID
Роберт Харви
Для меня что-то вроде from me.myproject.uuid import UUID, GetUUIDInfoвыглядит хорошо. В модуле может быть более одной экспортированной вещи.
9000
2
У JXTA есть пакеты 'id' для вещей, имеющих отношение к идентификаторам.
greg-449
@ greg-449 - Я склоняюсь к вашему предложению identityили identifiersдобавлю немного более подробного объяснения. В качестве ответа оно, вероятно, будет принято.

Ответы:

11

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

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

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

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

Майк Накис
источник
2
Пожалуйста, постарайтесь ограничить количество комментариев в ответах, которые не увеличивают полезность ответа. Раздел комментариев зарезервирован для таких заявлений об отказе. Спасибо.
maple_shaft
1

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

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

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

QBD
источник
1
Это мой подход. Не имеет смысла создавать пакет, который не имеет четкой цели. Если класс не может быть легко назначен значимому пакету, тогда 'util' - это хорошо, и, возможно, даже предпочтительнее. Обычно, когда вы идете дальше, в утилите в конечном итоге оказывается достаточно классов, связанных между собой, и их легко преобразовать из утилит (по крайней мере, во время разработки) в значимые пакеты. Если вы попытались создать уникальные пакеты для каждого класса, который вы не знаете, куда он идет, то вы можете легко упустить эти отношения и возможность реорганизовать в более чистую архитектуру.
Данк
@Dunk, на самом деле это очень хороший момент - преждевременное создание несколько искусственной структуры пакета не позволит вам увидеть более совершенную, более естественную организацию.
2015 г.
1

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

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

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

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

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

Hbas
источник
1
dtoсемантически бесполезен, как libи utils, вся dtoконцепция является наивным анти-паттерном середины 90-х годов и modelотносится к той же категории бесполезных обобщений
Мы недостаточно знаем о вашем проекте, чтобы дать вам больше полезных имен
Hbas
-2

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

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

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

Тибериу С.
источник
2
Примеры классов ALLCAPS в Java: java.util.UUID, java.net.URL, java.util.zip.CRC32и т.д.
scriptin
@scriptin Не было бы проще для разработчика, если бы он мог отличить только стиль прописных букв от класса «константа», члена от имени пакета и т. д.? Почему вы думаете, что CRC32, UUID - хорошее имя для класса, просто потому, что это сделал java? Или потому, что это аббревиатура от «Универсально уникальный идентификатор» или «Проверка циклическим избыточным кодом» ... но подождите немного! Что с этим java.util.zip.GZIPOutputStreamклассом? GZIPрасшифровывается как ... ? there is also a java.util.zip.ZipOutputStream`
Tiberiu C.
1
Классы - это типы, константы - это значения, здесь нет путаницы. Я не думаю, что эти имена хорошие или плохие, я просто указываю, что стили (кодирования), о которых вы говорите, не заставляют классы иметь строчные буквы. В Python UUIDтоже прописные.
скрипт
Если вы видите / поддерживаете код каждый день, стиль его делает разницу между «легко читаемой» и «перемоткой вперед и назад» фиестой, выделяя здесь только стиль прописных букв, я думаю, что это более ценно выразить через прописные буквы, тип члена (класс, константа, пакет и т. д.), а не тот факт, что является аббревиатурой.
Тибериу С.
1
Исходный вопрос не имел никакого отношения к тому, какой регистр букв использовать при написании имени пакета. Семантически UUID ничем не отличается от Uuid, uuid, UuId, UuID или любых других схем произвольной капитализации, которые вы считаете «лучшими».
Брандин