Существуют ли рекомендации по организации пакетов (Java)? [закрытый]

я организовываю пакеты по функциям, а не по шаблонам или ролям реализации. Я думаю, что пакеты, как:

• фасоль
• фабрики
• коллекции

ошибаетесь. Я предпочитаю, например:

• заказы
• магазине
• отчеты

поэтому я могу скрыть детали реализации через видимость пакета: фабрика заказов должна быть в пакете заказов, поэтому подробности о том, как Создать заказ скрыты.

короткий ответ: один пакет на модуль/функцию, возможно, с подпакетами. Поставить тесно связанные вещи вместе в одном пакете. Избегайте циклических зависимостей между пакетами.

ответ: Я согласен с большей частью этой статьи

Я предпочитаю до слоя, но я думаю, это зависит от проекта. Рассмотрим ваши силы:

• зависимостей. Попробуйте свести к минимуму зависимости пакетов, особенно между функциями. При необходимости извлеките API.
• организация команды. В некоторых организациях команды работают над объектами, а в других-над слоями. Это влияет на организацию кода, его использование для формализации API или поощрения сотрудничества.
• развертывание и управление версиями. Положить все в модуль делает развертывание и управление версиями проще, но исправление ошибок сложнее. Разделение вещей обеспечивает лучший контроль, масштабируемость и доступность.
• реагировать на изменения. Хорошо организованный код гораздо проще изменить, чем большой ком грязи.
• размер (люди, и строк кода). Чем больше, тем более формализованным/стандартизированным он должен быть.
• значение/качество. Некоторые коды более важны, чем другие. API должны быть более стабильными, чем реализация. Поэтому нужно четко разделять.
• уровень абстракции и точки входа. Это должно быть возможно для постороннего человека, чтобы знать, что такое код, и где начать чтение, глядя на дерево пакетов.

пример:

com/company/module
  + feature1/
    - MainClass          // The entry point for exploring
    + api/               // Public interface, used by other features
    + domain/
      - AggregateRoot
      + api/             // Internal API, complements the public, used by web
      + impl/ 
    + persistence/       
    + web/               // presentation layer 
    + services/          // Rest or other remote API 
    + support/            
  + feature2/
  + support/             // Any support or utils used by more than on feaure
    + io
    + config
    + persistence
    + web

Это просто пример. Это вполне официально. Например, он определяет 2 интерфейса для feature1. Обычно это не требуется, но может быть хорошей идеей, если используется по-разному различными людьми. Вы можете позволить внутреннему API для расширения публики.

мне не нравятся имена "impl" или "support", но они помогают отделить менее важные вещи от важных (домен и api). Когда дело доходит до именования, мне нравится быть максимально конкретным. Если у вас есть пакет под названием "utils" с 20 классами, переместите StringUtils в support/string, HttpUtil в support/http и так далее.

существуют ли лучшие практики в отношении организации пакетов в Java и что в них входит?

не совсем нет. Есть много идей и много мнений, но "лучшая практика" - это использовать свой здравый смысл!

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

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

Я должен также добавить, что есть и одним из широко нормы для имен пакетов. И это означает, что ваши имена пакетов должны начинаться с доменного имени вашей организации в обратном порядке. Если вы будете следовать этому правилу, вы уменьшите вероятность проблем, вызванных вашим (полным) именем класса, сталкивающимся с другими людьми.

Я видел, как некоторые люди продвигают "пакет по функции" над "пакетом по слою", но я использовал довольно много подходов на протяжении многих лет и нашел "пакет по слою" намного лучше, чем "пакет по функции".

кроме того, я обнаружил, что гибридная стратегия: "пакет по модулю, слой затем функция" работает очень хорошо на практике, поскольку она имеет много преимуществ "пакет по функции":

• способствует созданию многоразовых фреймворков (библиотек с обеими моделями и Аспекты пользовательского интерфейса)
• позволяет подключи и играй реализации слоя-практически невозможно с "пакетом по функции", потому что он помещает реализации слоя в тот же пакет/каталог, что и код модели.
• многое другое...

Я подробно объясняю здесь:структура и организация имени пакета Java но моя стандартная структура пакета это:

revdomain.moduleType.имя модуля.слой.[layerImpl].особенность.субфитюрен.subfeatureN+1...

где:

revdomain обратный домен, например, com.название_компании

moduleType [app* / framework / util]

moduleName например, myAppName, если тип модуля-это приложение или "финансы", если его структура учета

пласт [model / ui / persistence / security так далее.,]

layerImpl например., калитка, jsp, jpa, jdo, hibernate (Примечание: не используется, если слой является моделью)

feature например. финансы

subfeatureN например., бухгалтерия

subfeatureN+1 например. амортизация

*иногда "приложение" не учитывается, если moduleType является приложением, но ввод его туда делает структуру пакета согласованной во всех типах модулей.

Я не знаю стандартных методов организации пакетов. Обычно я создаю пакеты, которые охватывают достаточно широкий спектр, но я могу различать внутри проекта. Например, личный проект, над которым я сейчас работаю, имеет пакет, посвященный моим настраиваемым элементам управления UI (полный классов подклассов swing-классов). У меня есть пакет, посвященный моим материалам управления базами данных, у меня есть пакет для набора слушателей/событий, которые я создал, и так далее.

на с другой стороны, у меня был коллега, который создал новый пакет почти для всего, что он сделал. Каждый отдельный MVC, который он хотел, получил свой собственный пакет, и казалось, что набор MVC был единственной группой классов, разрешенной в одном пакете. Я помню, в какой-то момент у него было 5 разных пакетов, в каждом из которых был один класс. Я думаю, что его метод немного экстремален (и команда заставила его уменьшить количество пакетов, когда мы просто не могли справиться с этим), но для нетривиального приложения, так что складываю все в один пакет. Это точка равновесия, которую вы и ваши товарищи по команде должны найти для себя.

одна вещь, которую вы можете сделать, это попытаться отступить и подумать: если бы Вы были новым участником, представленным в проекте, или ваш проект был выпущен как open source или API, насколько легко/трудно было бы найти то, что вы хотите? Потому что для меня это то, что я действительно хочу из пакетов: организация. Подобно тому, как я храню файлы в папке на своем компьютере, я ожидаю, что смогу найти они снова без необходимости искать весь мой диск. Я исключаю возможность найти класс, который я хочу, без необходимости искать список всех классов в пакете.

Я обычно организовываю по слоям, потому что я пишу много веб-приложений. Поэтому у меня будет настойчивость, сервис, Модель, Вид, util и т. д.