This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am facing a problem which I think cannot be solved too easily, but I will try to share it with you in the hope someboby may give me a good idea..
I have the following situation:
Several classes implement this interface each listening to a specific kind of message. Such listeners are registered at the application startup (through Spring), and each time a message of type T arrives (via JMS), the corresponding receiveMsg(T msg) is invoked by a Message dispatcher.
Now, I want to extend these listeners to act as MsgMatcher<T> instead of simple "listeners", but without changing anything in their original implementation .. The difference between listeners and matcher is that the latest can "parse" the message content and decide if a given message has to be discarded or dispatched to a client. Of course, I would like to promote my Listeners to Matchers without changing any line of legacy code (too dangerous! ).. So I thought of Decorator pattern:
I would like to have something like this:
So, every time (in new code) I want to promote a listener to matcher I will do:
Of course, this solution won't work, since the message dispatcher will not get its reference to the listener updated (will invoke the receiveMsg() of MsgListener). Hence, I am afraid I have to intervene somewhere at the root of the problem (Spring startup?), my question is how?
As I told, I have to cope with a huge project where every change can be dangerous, and I would like to minimize the side effects of such changes..