Есть ли лучшие практики для (Java) организация пакета? [закрытый]

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

• beans
• фабрики
• коллекции

, ошибочны.

Я предпочитаю, например:

• заказы
• хранят
• отчеты

, поэтому я могу скрыть детали реализации с помощью видимости пакета . Фабрика заказов должна быть в пакете orders , поэтому подробности о том, как создать заказ, скрыты.

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

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

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

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

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

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

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

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