• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Mediator�s UML

 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good Day,

The following link shows the Mediator's UML, pretty much as the GoF book has it - http://www.dofactory.com/Patterns/PatternMediator.aspx.

I wonder whether the following change will be correct:
Removing the association from Colleague to Mediator and making the ConcreteMediator association to ConcreteColleague2 a bi-directional one.

Any thoughts?

Thanks,
Dan

P.S. For the first time for me, I remembered to check the Email Notification feature.
Ajith, is there a way to do it for threads to which we respond?
 
Deepak Pant
Ranch Hand
Posts: 446
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dan Drillich:
[QB]
I wonder whether the following change will be correct:
Removing the association from Colleague to Mediator and making the ConcreteMediator association to ConcreteColleague2 a bi-directional one.

Any thoughts?
QB]


Dan,

What are you trying to achieve ? Mediator is typically implemented as Interface where as ConcreteMediator will be an implementation.

I am confused on what you want to achieve.

regards,
Deepak
 
subramanian radhakrishnan
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dan Drillich:
Good Day,

The following link shows the Mediator's UML, pretty much as the GoF book has it - http://www.dofactory.com/Patterns/PatternMediator.aspx.

I wonder whether the following change will be correct:
Removing the association from Colleague to Mediator and making the ConcreteMediator association to ConcreteColleague2 a bi-directional one.

Any thoughts?

Thanks,
Dan

P.S. For the first time for me, I remembered to check the Email Notification feature.
Ajith, is there a way to do it for threads to which we respond?



Dan,

When u say removing the link between collegue to mediator the contract [interface level] is LOST...So u cannot do that.

Then on the bidirectional link: it is mostly bidiectional though not explicity given. because every collegue has a reference to the mediator and mediator [maintains and hence] has the reference to all the collegues....

for instance, if u take the front controller (mediator) pattern, where each view (collegue) knows its controller to ask for the transition on an event. Controller instantiates the appropriate view [as a result of the event]...

here the association is bidirectional.....

hope this helps.
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good Day,

If you look at the diagram at about the middle of the page http://my.execpc.com/~gopalan/design/behavioral/mediator/mediator.html.

My question is: Can we drop the _aMediator association and make the aNextColleague and _aOneColleague bi-directional associations?

It just seems simpler ....

-- Dan
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you were to read out the diagram loudly it says "A Colleague is associated with a Mediator. NextColleague and OneColleague are types of Colleagues"

If you changed the diagram per your suggestion( and if I have understood your question well ), it would then read "NextColleague and OneColleague are associated with ConcreteMediator"

Is there a difference between the two? You bet! The diagram in the original form explicitly indicates relationships at the type level( the "interface level") The same relationship is "inferred" ie., holds good but not represented between all implementations of the type "Colleague" and "Mediator". By changing the diagram per your suggestion, the relationship at the interface level is lost or at least unclear since you will then have chosen to depict the relationships between concerete entities only.

The key here is a concept called "Design by contract". You define base types and define contracts among them. And then you go on and extend those types( or implement them, ) while still satisfying the contract. As a good practice, you should always show the relationships between base types ( or even better interfaces ). This makes the representation valid even after you introduce a gazillion different implementations for each associated type. On the other hand, if you represent relationships at the concrete implementation level, it might make the diagram inaccurately represent or completely omit the relationships between base types. Not to forget, it makes the diagram more cluttered.

Hope this helps!
 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Ajith!

So now I don't understand if it's possible to draw the associations between the mediator and the colleagues at the interface level.

-- Dan
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The relationship at the interface level is already shown in the diagram.

 
Dan Drillich
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ajith,

My question is about the other direction, meaning making _aMediator a bi-directional association and dropping the _aNextColleague and _aOneColleague ones.

Thanks,
Dan
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic