Как соломенный эксперт, посчитайте, что пакет 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
выглядит хорошо. В модуле может быть более одной экспортированной вещи.identity
илиidentifiers
добавлю немного более подробного объяснения. В качестве ответа оно, вероятно, будет принято.Ответы:
Проблема с попыткой поместить каждый класс в пакет, который имеет семантически правильное имя для этого класса, состоит в том, что он имеет тенденцию приводить к пакетам, которые содержат очень мало классов, а иногда даже только один класс. Это, в свою очередь, приводит к множеству пакетов.
Более прагматичный подход к именованию пакетов - просто помочь вам найти материал. Хранение часто используемых вещей, которые вы всегда знаете, где найти все в одном месте, мешает им в пути и, следовательно, облегчает поиск более редко используемых вещей. Таким образом, вам на самом деле не нужны имена пакетов, которые семантически правильны для каждого из классов, которые они содержат, вам просто нужны имена пакетов, которые не являются семантически некорректными. Очевидно, что «Util» имя пакета был выбран в соответствии с этой линии мышления: не семантически правильное название для классов , которые он содержит, но это также не семантически неверно, и это достаточно хорошо.
Итак, если ваш тип UUID предназначен для использования только этим конкретным приложением (о чем свидетельствует тот факт, что вы планируете поместить его в «myproject»), то он, вероятно, является частью «модели» вашего проект. У вас уже должен быть пакет 'model', содержащий набор всех классов, которые соответствуют вашим постоянным объектам, многие из которых, вероятно, имеют отношения между ними, причем UUID, вероятно, являются средством реализации этих отношений. Кроме того, ваши UUID, вероятно, знают, как сохранить себя, верно? Кроме того, ваши UUID, вероятно, могут быть найдены только как члены вашей модели сущностей, верно? Таким образом, ваша модель пакета, вероятно, лучшее место для этого.
В противном случае, если этот тип вашего UUID может быть использован и в других проектах, его необходимо рассматривать как часть некоторой структуры. Таким образом, он может находиться в корневой папке исходного кода этой платформы или в некоторых подпакетах «types», как предложила MainMa, или даже в некотором подпакете этой платформы, называемом «util» или «misc». В этом нет ничего плохого.
источник
Назначение пакетов - группировать классы в соответствии с некоторыми критериями (пакет по типу / слою, пакет по элементу и т. Д.). Я не вижу смысла создавать пакет только для одного класса, особенно если вы не ожидаете, что в будущем в этом пакете будут другие классы.
Также я думаю, что имя пакета «util» не является полностью бессмысленным - оно просто группирует классы по определенным критериям - для меня класс «util» означает, что оно не является частью домена приложения, но оно также не является частью фреймворк (не влияет на структуру приложения). По сути, это просто расширение (не) стандартной библиотеки.
В этом случае у меня не было бы проблемы с помещением этого класса UUID в пакет «util». Если будут некоторые другие связанные с UUID служебные классы (например, отдельный класс для генерации UUID), то для них будет легко провести рефакторинг и создать пакет «util.uuid» (если только вы не создаете библиотеку, и UUID будет частью открытого интерфейса). тогда нужно быть немного «дальновидным»).
источник
У дяди Боба есть некоторые рекомендации по разделению пакетов.
Первые три принципа пакета касаются сплоченности пакета, они говорят нам, что поместить в пакеты:
Итак, отвечая на ваш вопрос, кто / что собирается использовать класс UUID, использовать его в качестве атрибута или вызывать в нем операции? Как твой график зависимости ? UUID будет использоваться вместе с какими другими классами ?
В зависимости от вашего ответа, может быть , вы должны назвать это me.myproject.identity пакет, me.myproject.serialization пакет, me.myproject. DTO или даже что-то еще полностью. Возможно, класс UUID должен храниться вместе с вашими моделями, и вы поместите его в пакет, который у вас уже есть, например, me.myproject.models .
источник
dto
семантически бесполезен, какlib
иutils
, всяdto
концепция является наивным анти-паттерном середины 90-х годов иmodel
относится к той же категории бесполезных обобщенийПрежде всего, UUID (с заглавными буквами) кажется мне очень плохой идеей для имени пакета или имени класса, так как все стили, применяемые так или иначе, все имена в верхнем регистре связаны с «константами». Пакеты предназначены для упорядочивания вещей, самый простой способ назвать пакет по значению классов, которые он содержит:
com.example.identifier
;com.example.uuid
.Сделайте это простым
источник
java.util.UUID
,java.net.URL
,java.util.zip.CRC32
и т.д.java.util.zip.GZIPOutputStream
классом?GZIP
расшифровывается как ...? there is also a
java.util.zip.ZipOutputStream`UUID
тоже прописные.