2010-03-26 4 views
0

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

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

Теперь, поскольку этот класс настроек применяется ко всему проекту, я не уверен, что он должен быть упакован, и если да, то в каком пакете он должен существовать? Или он должен быть в корне (пакет по умолчанию) с основным классом приложения?

Я думал о том, чтобы поместить его в мой пакет utils, и снова я не думаю, что это действительно является utlity. Какие-либо стратегии о том, как решить такую ​​структуру пакетов, например, для класса настроек?

ответ

1

Использование пакета по умолчанию в любом случае обескураживает (в java оно фактически применяется как предупреждение, насколько я знаю) даже для класса, содержащего основной.

Кроме этого, я предпочитаю иметь пакет config, даже если он является единственным классом. Я не думаю, что это поместило бы в пакет utils.

+0

Есть ли пакет с тем же именем, что и единственный объект, который он содержит, действительно поощряемый? Я думал, что пакеты предназначены для группировки нескольких классов вместе, поэтому наличие только 1 класса для пакета не кажется мне правильным, может быть, я ошибаюсь? – Tom

+0

Пакеты предназначены для группировки классов логически - если есть только один класс с этой конкретной целью, я не понимаю, почему бы не оставить его там в одиночку. Класс «Настройки», конечно же, не имеет ничего общего с утилит для проекта, он имеет отношение к настройке. Другим вариантом, с которым вам было бы лучше, было бы поставить его на вершину иерархии, то есть для пакета 'com.some_comp.some_software. ', 'Settings' будет на том же уровне с' < different_packages> 'part, at' com.some_comp.some_software.Settings'. – laura

0

IMHO вы должны поместить его в отдельный пакет низкого уровня, так как от него зависят многие другие классы, но он (предположительно) не зависит ни от чего. Таким образом, должно быть установлено не в одном пакете с основным классом приложения. Это может быть в пакете utils, хотя или в отдельном пакете на том же уровне (например, config).

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

Кстати, вы не должны использовать корневой пакет в реальном приложении.

Смежные вопросы