Плюсы и минусы организации пакетов в проекте Java

Question

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

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

Спасибо за ваши посты.

Answer 1

Пакеты предназначены, чтобы помочь вам найти вещи.

Если они делают это более запутанным, чем оно есть, вы делаете что-то не совсем правильно. Если структура пакета не интуитивна, на самом деле найти классы сложнее, чем в плоской структуре.

Насколько я знаю, есть две базовые школы организации классов в пакеты:

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

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

Действительно важно следовать одной системе, а не смешивать ее с другой. Не вводите классы в чистые пакеты, к которым они не принадлежат, и не бойтесь создавать новый пакет, если ваш новый класс, похоже, не принадлежит ни к одному из ваших существующих.

Если пакет кажется слишком большим, вы можете разделить его. Но решение о том, должен ли пакет делиться или нет, должно приниматься относительно того, существует ли четкое концептуальное разделение между классами в нем, а не по числам. Пакет с одним классом так же хорош, как пакет с тридцатью классами, если очевидно, почему они там есть.

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

Но если у вас есть несколько реализаций для данного интерфейса, тогда да, я бы разделил их. Интерфейс будет com.foo.Bar, а реализации будут, например, com.foo.bars.CrowBar, com.foo.bars.TaskBar. Очевидно, что если ваши реализации принадлежат разным модулям, вы бы изменили его на com.foo.moduleX.bars.CrowBar или com.foo.bars.moduleX.CrowBar, в зависимости от того, какую систему вы используете.

Перечитывая все это, это звучит довольно сложно, но, вероятно, первое предложение является самым важным: не следуйте принципам упаковки вслепую, пакеты должны помочь вам найти классы, а не помешать вам.

Answer 2

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

Я предпочитаю отделять объекты бизнес-данных (DAO) от их репозиториев / служб извлечения, которые отделены от объектов и представлений бизнес-логики.

Наборы связанных функций без перекрестных зависимостей имеют тенденцию переходить в свой собственный артефакт какЯ склонен повторно использовать логику.Особенно удобно, когда вы начинаете играть с OSGi и независимыми сервисами.

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