Должны ли мои внутренние классы API быть в одном пакете?

Question

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

Проблема в том, что у меня много внутреннего кода, которому нужен доступ к этим закрытым методам, не делая эти методы общедоступными. Это создает две проблемы:

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

Итак, у меня есть около 70 или 80 внутренних классов в четко разделенных пакетах, НО с чрезмерно разрешающими модификаторами доступа. Вы сказали бы, что один пакет - меньшее из двух зол или есть лучший способ маскировать мои внутренние методы, сохраняя при этом более детальные пакеты?

Мне было бы интересно узнать лучшие практики здесь.

Я уже в курсе Это

Answer 1

Есть два решения для вашего вопроса, которые не включают хранение всех классов в одном пакете.

Во-первых, необходимо использовать шаблон Friend Accessor / Friend Package , описанный в (Практическое проектирование API, Tulach 2008).

Второе - использовать OSGi. Есть статья здесь , объясняющая, как OSGi выполняет это.

Смежные вопросы: 1 , 2 , 3 и 4 .

Answer 2

Одним из примеров может быть API сервлетов , как вы видите, они разделили общий API сервлетов и http на два пакета.

Если вы разделяете свой код на api.jar и implementation.jar, вы можете использовать интерфейсы для своей реализации, которые не видны пользователям api.jar. Если объекты классов независимо от их пакета должны каким-либо образом взаимодействовать, методы, конечно, должны быть видны (по крайней мере, в реализации).

Answer 3

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

Мне нравится соглашение о добавлении публично видимых артефактов в пакет / api и внутренних элементов в / internal . В конце концов вы получите.

# this package is allowed to be accessed by api-users
com.foo.users.api
# this is completely internal logic (api implementation)
# should only be touched by the api-module itself.
com.foo.users.internal

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

Как и в случае с сервлет-api, упомянутым выше, вы можете еще больше разделить api и impl на разные банки. Но это требует больше усилий для сборки жизненного цикла и обслуживания модулей, поэтому я бы делал это только тогда, когда имеет смысл полное разделение артефактов во время выполнения (как в jsr-spec vs. impl).