osgi экспорт реализации для наследования

Question

На основе передового опыта, который я читал в разных местах (one example), он идеально подходит для разделения API и реализации, но также и для экспорта пакетов в комплекте API, а не в пакет реализации, который должен регистрироваться как услуга.

Однако я до сих пор неясно, как вы должны распространять конкретный класс. Мне кажется, что, чтобы быть в состоянии сделать

class Child extends com.foo.ParentImpl { 
} 

в осущ сверток должен был бы выставить com.foo

AFAIU есть только два способа

1. Экспорт конкретной реализации, но это нарушает наилучшая практика
2. Никогда не расширяйте классы из другого набора. объедините все иерархии типов. Этот вид поражает точку модульной структуры, на мой взгляд.

Так что это правильный способ сделать это?

Answer 1

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

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

Так что я бы посоветовал забыть о наследовании. Это переоценено.

Если вы действительно хотите сделать это, а затем сохранить иерархию вместе, в соответствии с вашим номером опции 2.

Answer 2

TLDR: Разделительный API и реализация лучше всего оставить для вещей, которые вы выставлены в качестве служб OSGI, чьи экземпляры будут ссылаться на пакеты. В противном случае просто выведите свой класс как есть.

Тип модульности, который вы получаете в OSGI, не поддается расширению классов обслуживания. Вам гораздо лучше использовать шаблон дизайна, который будет позволит вам расширить функциональность ваших услуг.

Я также хотел бы знать, какой класс вы пытаетесь расширить и какова цель.

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

class MyExtendedService implements Service { 
    Service service; 
    //delegate to MyService which also implements Service and 
    // is pulled from another osgi bundle. 
} 

Теперь, если вы определяете классы, которые являются «вещью», как модель или значения объекта, то, вероятно, нет причин, чтобы иметь отдельный API и реализацию классов. Просто выставляйте их как есть.