Структура пакета OSGi-пакета

Question

Я думал о «хорошей практике» в отношении структуры пакетов внутри пакетов osgi. В настоящее время в среднем у нас около 8-12 классов на связку. Одна из моих инициатив / предложений заключалась в том, чтобы иметь два пакета; com.company_name.osgi.services.api (для api-классов / интерфейсов (которые экспортируются извне) и один пакет com.company_name.osgi.services.impl для реализации (не экспортируется)). Каковы плюсы и минусы этого? Любые другие предложения?

Answer 1

Вы можете также рассмотреть возможность помещения интерфейсов в com.company_name.subsystem, а реализацию в com.company_name.subsystem.impl, специальный код OSGI, если таковой имеется, может быть в com.company_name.subsystem.osgi. Иногда у вас может быть несколько реализаций одного и того же интерфейса. В этом случае вы можете рассмотреть - com.company_name.subsystem.impl1 и com.company_name.subsystem.impl2, например:

com.company.scm        // the scm api
com.company.scm.git    // its git implementaton
com.company.scm.svn    // its subversion implementation
com.company.scm.osgi   // the place to put an OSGI Activator

В этом смысле структура пакета может быть независимой от OSGi, если вы позже перейдете в другой контейнер, вы просто добавите дополнительный

com.company.scm.sca     // or whatever component model you might think of

Всегда иметь api и impl в имени вашего пакета может раздражать. В случае сомнений используйте impl, но не api.

Answer 2

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

Важно то, что вы разделяете API и реализацию. Один комплект содержит API вашей концепции, а другой - реализацию. Таким образом, вы можете предоставить различные реализации для четко определенного API. В некоторых случаях это может быть даже необходимо, если вы хотите получить доступ к службам из пакета удаленно (например, с помощью R-OGSi)

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

Answer 3

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