Concrete classes in OSGI API bundle

Question

I am building a service for cleansing physical addresses. I have an API bundle that contains an interface with a cleanse method. This method would take in a list of raw address data. I would then have an implementation bundle that would implement the cleanse method and expose a service. Client bundles would then have a dependency on the API bundle and have a reference to the exposed service. I'm struggling with figuring out the "best" way to do it. I am thinking of two options:

Option 1:
The API bundle has a RawAddress value class. This means I have a concrete class in the API bundle, which I believe is frowned upon in the OSGI world, or at least is not a best practice (see Is separate OSGI bundles for api and implementation common practice? - especially Neil's comment on the accepted answer).

From the client perspective:

List<RawAddress> rawAddresses = new ArrayList<>();
for(...) {
    RawAddress address = new RawAddress(addrLine, city, state, zip);
    rawAddresses.add(address);
}
List<CleanAddress> cleanAddresses = addressService.cleanse(rawAddresses);

Option 2:
RawAddress is instead an interface in the API bundle. The AddressService object would have an additional method for creating objects that implement RawAddress. This leaves the API bundle "pure" but it also feels like it may be overkill.

From the client perspective:

List<RawAddress> rawAddresses = new ArrayList<>();
for(...) {
    RawAddress address = addressService.newRawAddress(addrLine, city, state, zip);
    rawAddresses.add(address);
}
List<CleanAddress> cleanAddresses = addressService.cleanse(rawAddresses);

I feel like I'm over-thinking this and/or that I'm missing some better solution. Any thoughts?

BJ Hargrave · Answer 1 · 2017-04-10T17:13:38.367

Either is fine. It depends upon how "big" the implementation of the concrete class is. If it is simple and basically a data holder with a constructor and getters such that any possible implementation of your service would use the concrete class, then putting the concrete class in the API package is fine. However, if the concrete class is complex and different implementations may want to implement it differently to provide some value add, then just using an interface in the API package would be a better choice.

score 3 · Accepted Answer · answered Mar 15 '14 at 16:28

I would say it really depends on the exact functionality present in your RawAddress and CleanAddress classes. If these are mere POJOs with just setters/getters to private members and as such used as parameters to your API functionality, I don't see a problem in including them in the API bundle. The indication that API bundles should only contain interfaces is largely related to the actual functionality of the API (that has the tendency to change over time or can be implemented in different ways) and less to the parameters of that API.

Personally, I use only interfaces in the APIs, even for the parameters, but provide a simple implementation in the API bundle if the parameters used in the API methods are POJOs.

Hope this helps somewhat.

Thank you, this helps clear up my confusion. As you surmised, the RawAddress class is indeed just a POJO with no interesting behavior. I went with your suggestion of providing a default implementation in the API. I am happy with this compromise. — jblack801, Mar 18 '14 at 00:09

Concrete classes in OSGI API bundle

2 Answers2