I have an application which is pretty modular, means i have about 12 components, each as stand-alone OSGi bundle. They communicate and another user is able to write his own stuff, bundles, etc. which listens to the messages or even send messages to other components. I am now wondering whats the "best practice" way of creating such messages. When i use a listener-like interface which has a abstract Message object which contains the payload i have to use a lot of instanceof calls. At the moment i am using the EventAdmin (part of OSGi) which sends these messages to the "bus" (iirc this is done somehow like SOAP internal in the OSGi framework). But here i have the problem that i have to define all messages which are possible, in a nice way, so that the user can easily find what he has to send and what he is going to get. A little example:
This is a part of the "downloader engine" component. I guess my problem is now clear
I have to documentate each possible message in a very detailed way which is a _big load_ of information when i create that with javadoc or such.
When i want to send a song:
All components which want to catch this event has to know now what is inside this message object. So i am thinking of changing the API to builders and create a builder for each possible message - thats a lot of work and not nice to maintain but i guess thats easier for others to write bundles...
Is there some kind of pattern for this? Or any hints whats the "best way" in doing this?
I would use a chain of responsibility pattern along with the builder pattern. You can have a list of processors; one for each type of Song; and a list of builders; one for each type of song. This way you can have the builder and the processor neatly bundled n one package, so all the code for each type of song lives together in one package, and also it will be easy to add new types of songs.
Joined: Jun 20, 2009
Hi, thanks for your answer. I am wondering how the chain of responsibility pattern should be realized. Its not that hard song related, so a message can also be just "SHOWBROWSERGUI" or "SHOWPLAYERGUI", which has no parameters and only a topic to identify it.
Can you maybe provide a little bit of example code? I just found some code for eg. loggers on the internet but i dont understand how to integrate this into my application.
olze oli wrote:Hi, thanks for your answer. I am wondering how the chain of responsibility pattern should be realized.
Not having used OSGi, I'm wondering if there isn't any literature provided by it on the best ways of handling such a situation.
If I get it right, your basic problem is this:
1. You have a download, which contains a payload of some indeterminate type.
2. You want to design a framework that handles each download in the applicable manner for its type without writing a bunch of dispatch code.
Now, the normal way to do this, if the type were known in advance (ie, at compile time), would be to use polymorphism, but you only know the type at runtime. One possible solution is to use reflection, but I'd advise against it unless you really don't see any other choice.
Another is, as Kayesh suggested, to implement a Chain of Responsibility, which may be particularly apt if your payload types lend themselves to some sort of hierarchy. And yet another might be to look at the Visitor pattern. You may even want some combination of the two.
I'm afraid it would take too long to provide a complete implementation here, but hopefully the links give you something to work with (I believe both have Java examples).
I'd also suggest getting a good book on design patterns (of which the granddaddy is this one), because it sounds like you're going to need one.
Bats fly at night, 'cause they aren't we. And if we tried, we'd hit a tree -- Ogden Nash (or should've been).
Articles by Winston can be found here