Подтвердить что ты не робот

Должно ли имя класса Java дублировать имя пакета?

Я думаю о том, что является лучшей практикой в Java для следующего случая:

У меня есть логика в моей программе, которую я хочу добавить в отдельный пакет.

Например (мой текущий случай), это логика, которая будет собирать некоторые статистические данные, а затем отправлять их на сервер). Поэтому мой пакет под моим проектом com.example.project будет называться com.example.project.statistics.

Внутри пакета будут несколько классов, в данном случае - статистикаDispatcher (в основном контейнер и менеджер событий) и StatisticsEvent (событие, которое должно быть рассчитано в статистику).

Вопрос в том, какое соглашение об именах следует использовать? Я вижу два варианта:

  1. StatisticsDispatcher и StatisticsEvent, как указано выше. Имя класса дает понять, что делает класс, но является немного неоднозначным в абсолютном имени, например com.example.project.statistics.StatisticsEvent.
  2. Диспетчер и событие. Он короче, и цель класса понятна из его абсолютного имени, например com.example.project.statistics.Dispatcher, но позже в коде эти имена могут быть неоднозначными с классами других пакетов, и даже если нет, когда я импортируйте эти классы в начале файла, имена классов, такие как "Диспетчер" и "Событие", являются очень общими, а в середине файла не будет видно, к чему они относятся.

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

заранее спасибо

4b9b3361

Ответ 1

Я предпочел бы быть явным (и, возможно, подробным), чтобы быть кратким (и, возможно, двусмысленным).

Ваш пример re. Dispatcher/Event является хорошим. Если вам не повезло, вам придется полностью квалифицировать каждое их возникновение, чтобы разрешить любые двусмысленности.

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

Ответ 2

Я обязательно пойду для первого, то есть StatisticsDispatcher и StatisticsEvent, потому что слова Dispatcher и Event, используемые сами по себе, могут означать много вещей (особенно в Java EE).

Ответ 3

Я также определенно буду искать менее двусмысленные имена. Использование любых имен, которые могут конфликтовать с другими пакетами:

  • вызывает проблемы для человека, читающего код. Если я увижу "Событие", то я могу считать его общей библиотекой Java, и единственный способ разрешить это - прочитать выражение на import.
  • вызывает проблемы для IDE. Например, Eclipse иногда "полезно" угадывает наиболее вероятный пакет. Список, Элемент, Атрибут и т.д. Могут быть импортированы из пакетов, которые вы даже не знали! И это может быть удивительным количеством потраченного впустую времени, чтобы отладить это.