Структура пакета 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.В некоторых случаях это может быть даже необходимо, если вы хотите получить удаленный доступ к службам из пакета (например, с помощьюР-ОГСи)

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

Answer 3

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