Пакет представляет собой набор кода, который изменяется вместе, используется вместе и поставляется вместе.Итак, баночка / война - это пакет.
Принципы проектирования пакетов
Я понимаю, что вы имели в виду пакет с исходным кодом, который больше похож на структуру каталогов.Но я считаю, что каталог - это физическое представление на жестком диске.
РЕДАКТИРОВАТЬ: У меня был оригинальный ответ более 3 лет назад.Но не изменилось, как это было принято.Но измените его сейчас, чтобы любой новый посетитель мог получить выгоду, а также избежать гниения ссылок.Некоторое дополнительное значение пакета может быть извлечено на основе обсуждения ниже.Например, является ли jar пакетом?
Классы, которые повторно используются вместе, должны быть упакованы вместе, чтобы пакет можно было рассматривать как своего рода готовый продукт, доступный для вас.И те, которые повторно используются вместе, должны быть отделены от тех, с которыми не используются повторно.Например, ваши служебные классы Logging не обязательно используются вместе с вашими файловыми классами.Так что упаковывайте все, регистрируя их отдельно.Но классы журналирования могут быть связаны друг с другом.Так что создайте своего рода законченный продукт для регистрации, скажем, из-за отсутствия лучшего имени, com-logging упакуйте его в (повторно) пригодный для использования jar и другой отдельный полный продукт для утилит io, опять же из-за отсутствия лучшего имени, скажем, commons-io.jar.Если вы обновите, скажем, библиотеку commons-io, указав поддержку java nio, то вам необязательно вносить какие-либо изменения в библиотеку журналов.Так что разделять их лучше.
Теперь предположим, что вы хотели, чтобы ваши служебные классы журналирования поддерживали структурированное ведение журналов, например, для анализа журналов с помощью таких инструментов, как splunk.Некоторые клиенты вашей утилиты регистрации могут захотеть обновиться до вашей новой версии;некоторые другие не могут.Поэтому, когда вы выпускаете новую версию, упаковывайте все классы, которые необходимы и повторно используются для миграции.Таким образом, некоторые клиенты ваших служебных классов могут безопасно удалить ваш старый jar-файл регистрации общего ресурса и перейти на jar-файл commons-logging-new.Некоторые другие клиенты все еще в порядке со старыми банками.Однако клиентам не требуется иметь оба этих jar-файла (новый и старый) только потому, что вы заставили их использовать некоторые классы для старых упакованных jar-файлов.
Избегайте циклических зависимостей.а зависит от б;б на с;с на г;но d зависит от.Сценарий явно сдерживает, так как будет очень сложно определить слои или модули и т. Д., И вы не сможете изменять их независимо друг от друга.
Кроме того, вы можете упаковать свои классы так, чтобы при изменении слоя или модулядругие модули или слои не обязательно должны быть изменены.Так, например, если вы решите перейти от старой инфраструктуры MVC к обновлению остальных API, то изменения могут потребоваться только представлению и контроллеру;ваша модель не.