Folks, Please have a look at the following question. I found this on a comeercial mock exam.
A financial institution is building a J2EE based application for Order Entry and management of their equity software. Once the order is taken, it is submitted to a relational database. A provisioning system then queries data and makes appropriate calls to various subsystems using JMS on MQ series. What design pattern is JMS an example of here?(Choose 2)
a. Observer b. Mediator c. Adapter d. Bridge e. Visitor
The answer that are given: c) Adapter & d) Bridge
I always knew any asynchronous messaging system to simulate the Observer or Mediator pattern, and am surprised to find this answer. I would like to the viewpoint of other Ranchers on this. Do you think there is [ B]really[/B] any logic which justifies the answers given? (Adapter & Bridge), Or this is just another case of unscrupulous typing mistake by the mock examiners?
Apart from this, would any of you kindly explain (preferably with examples) what is the difference between the Observer & Mediator patterns? (I don't require definitions). Both of these seem same to me, and it is difficult to choose betwen the two when given only one option.
Originally posted by Goutam Bhattacharjee: Apart from this, would any of you kindly explain (preferably with examples) what is the difference between the Observer & Mediator patterns? (I don't require definitions). Both of these seem same to me, and it is difficult to choose betwen the two when given only one option.
Huh? If you don't require definitions (because you already know them) then I don't understand your problem because observer and mediator are quite different. So please try to explain, why they are not in your opinion. That way we have a chance to intervene without repeating things you already know.
In my opinion, Mediator basically acts as communictor, communicating messages between different objects transperently. It is basically many to many communication. Obeserver also handles communication between objects but it is generally one to many type. Also dependent objects are aware of observer as they need to subscribe for specific service in order to receive the communication.
Joined: Apr 25, 2003
Regarding your JMS question, I have seen this question earlier in some different post. The key point here is how you read the problem. If you look at just JMS as design patten then answer would be Observer. If ypu look where JMS fits in overall architetcure and which pattern is in place (using JMS) then answer would be different.
Joined: Aug 05, 2003
Harbo, The selection between observer and mediator seems quite blurred to me becoz both of them are used in asynchronous communication (like JMS) and both of them provide loose coupling between the individual communicators. I am actually looking for some example scenarios when both of these are provided as options, and you are asked to pick only 1 choice. Under this situation, how would you judge one of them to be the correct answer? What will be your basis of distinguishing between the two patterns? What logic will help you draw the fine line between these two? If you can explain the above points to me citing a few suitable examples, it will really be very helpful. Looking forward to hear from you, D.Rose and all others.
The biggest difference between Observer and Mediator pattern is as follows.
Using Mediator pattern, you are trying to decouple the objects who know about each other. But using Observer Pattern, you are trying notify the state changes of one object to the others who are not supposed to know about each other.
Hi Goutam, An example of a Mediator is a Controller in an MVC pattern. Instead of pages using hyperlinks to 'talk' to each other (i.e. many to many), they all go through a central point, the Controller, which then determines which page to display next.
The Observer pattern can be used when only Asynchronous communication is needed. An example is when the Petstore website passes order data (XML data via JMS)to the Order Fulfillment Centre.
My answer to the question would be (a)& (c). I would discount (d) 'Bridge' as this is a pattern that describes a link between an abstraction and implementation (not the case here). I would only choose (c) 'Adapter' as you need to make 2 choices. I don't think it is an adapter, but you are talking about linking 2 systems, so its the best fit from the other options.