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



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

Я не могу найти его сейчас, поэтому я могу также задать вопрос.

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

Как вы организуете свои классы в вашем проекте Java?

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

ваши мысли и комментарии приветствуются.

197   8  

8 ответов:

организация пакета или структурирование пакета обычно является жарким обсуждением. Ниже приведены некоторые простые рекомендации по именованию и структурированию пакетов:

  • следуйте java соглашения об именовании пакетов
  • структура пакетов в соответствии с их функциональной ролью, а также их бизнес-роли
    • разбейте ваши пакеты в соответствии с их функциональностью или модулями. например,com.company.product.modulea
    • дальнейшее разрушение может быть на основе слоев в вашем программном обеспечении. Но не переусердствуйте, если у вас есть только несколько классов в пакете, тогда имеет смысл иметь все в пакете. например,com.company.product.module.web или com.company.product.module.util etc.
    • избегите пойти за борт с составлять, ИМО избегите отдельной упаковки для исключений, фабрик, ЕТК. если нет острой необходимости.
  • если ваш проект небольшой, держите его простым с несколькими пакетами. например,com.company.product.model и com.company.product.util и т. д.
  • посмотреть на некоторые из популярных проектов с открытым исходным кодом на проекты Apache. Посмотрите, как они используют структурирование, для различных размеров проектов.
  • также учитывайте сборку и распространение при именовании (позволяя вам распространять свой api или SDK в другом пакете, см. servlet api)

после нескольких экспериментов и испытаний вы должны быть в состоянии придумать структуру, с которой вам удобно. Не зацикливайтесь на одной конвенции, будьте открыты изменения.

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

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

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

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

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

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

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

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

  • зависимостей. Попробуйте свести к минимуму зависимости пакетов, особенно между функциями. При необходимости извлеките 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 и т. д.

    Ничего не найдено.

Добавить ответ:
Отменить.