Help coderanch get a
new server
by contributing to the fundraiser
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

use of mediator pattern

 
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there any use of the mediator pattern if the mediator is not reusable across multiple objects.
For ex.If i have a screen that contains child components and if it also acts a mediator between components.Is there any use of implementing the mediator pattern if the mediator cannot be reused across multiple screens?
Thanks in advance
Willian
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would say such a mediator could still have value even if it's not reusable in other contexts. The purpose of a mediator is to avoid the screens themselves becoming coupled to each other and that goal is achieved regardless of how reusable (or unreusable) the mediator implementation is.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I hate to say that, but I fully agree with Lasse...
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
I would say such a mediator could still have value even if it's not reusable in other contexts. The purpose of a mediator is to avoid the screens themselves becoming coupled to each other and that goal is achieved regardless of how reusable (or unreusable) the mediator implementation is.



Thanks Lasse,
But can you elaborate on the benifit of this reduced coupling.I mean when i look at it from an implemenation point of view I am confronted with two choices
1.Go ahead and implement the behaviour across multiple components' action listeners and have one component refer another explicitly.(without using a mediator).
2.Have an additional class for mediator and have each component tell the mediator about how its state has changed and leave it to the mediator to talk to other components and update them.
What is the advantage i get by using option 2, which i suppose ,you are recommending?Why bring in an extra class?Why spend additional time trying to design the interface for the mediator and have the components adhere to it when it can be done in a straight forward way?
Please explain...
Thanks in advance
William
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The benefit of the added indirection is that your components become decoupled from each other in the sense that when you need to change one component, you probably don't have to change a dozen others -- which could easily be the case if all those dozen other components referenced the changing component directly.

In some cases, it's ok to couple them together. It certainly is "easier" to go the route of strong coupling at first. However, when doing that you should be aware of the risk you're accumulating.
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:
The benefit of the added indirection is that your components become decoupled from each other in the sense that when you need to change one component, you probably don't have to change a dozen others -- which could easily be the case if all those dozen other components referenced the changing component directly.

In some cases, it's ok to couple them together. It certainly is "easier" to go the route of strong coupling at first. However, when doing that you should be aware of the risk you're accumulating.


Thanks Lasse,
I get what you are saying.But earnestly i am not getting convinced the benifit of this decoupling and indirection that seems to be motive of all the design patterns.What I am not able to understand is 'How is using a mediator pattern more beneficial when compared to a class, for a say an InternalFrame, with private methods similar to methods in the mediator interface?' I know that my question is very elementary but I need to convince myself before i fully appreaciate the benifit for this pattern.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by william kane:
What I am not able to understand is 'How is using a mediator pattern more beneficial when compared to a class, for a say an InternalFrame, with private methods similar to methods in the mediator interface?'



It isn't - at least not in every case.

That is, it's quite likely the best approach to start with your InternalFrame as mentioned above.

But some time into development you might notice that your InternalFrame class becomes too big (*), that it looses coherence (doesn't conform to the Single Responsibility Principle any longer), that it becomes harder and harder to understand because of the complex logic involved.

*Then* is the time and place to think about how to restructure (refactor) your code to simplify it. And one of the options you have is to extract part of the logic into a Mediator object.

Does that help?

(*) To me, that might be quite early into development, because I like small, focused classes. Small meaning not more than perhaps a dozen methods, each not longer than a handfull of lines of code. That tends to make the code much more flexible and reusable, in my experience.
 
Bartender
Posts: 1205
22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by william kane:

Thanks Lasse,
I get what you are saying.But earnestly i am not getting convinced the benifit of this decoupling and indirection that seems to be motive of all the design patterns....



You are correct that the motivation behind many design patterns is to make later changes/extensions easier at the expense of some extra complication in the original design/implementation.

In the case of the Mediator, you are attempting to isolate the code that needs to change when changes to single class are made.

Try this: Think of some change that might be made to some frequently used low-level class in your system. If you change the interface of that class, particularly if it now extends a different base class, how many other source code files will you have to change? Now do that same exercise with a Meditor in the mix.

For example, let say you switch the widget you use to allow the user to select a state/province from a set of radio buttons to a dropdown menu. Without a Mediator, in addition to the StateSelector class, you would also have to change all the classes that use StateSelector: ShippingAddressInfo, BillingAddressInfo and WorkAddressInfo.

If you originally had a Mediator between those *AddressInfo classes and the StateSelector classes, in addition to chaging the StateSelector, you would only have to change the implementation of the Mediator methods from using radio button methods to calling dropdown methods in StateSelector. (Of course you would leave the Mediator method interfaces used by the *AddressInfo classes the same.)

Granted, if you know ahead of time that the requirements for your system will never change, then you have no need to consider many Design Patterns. ...but how often does that happen?

Ryan
[ March 21, 2005: Message edited by: Ryan McGuire ]
 
It's exactly the same and completely different as this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/t/782867/Coderanch-server-fundraiser
reply
    Bookmark Topic Watch Topic
  • New Topic