Mediator pattern or too much responsibility

Question

In my application, I have several components that have to know about each other, such as a menu bar and a tool bar that both need to know about the table to add or remove jobs and also to find out which job is selected.

So, I created a object called guiMediator that I pass to every object and they register themselves with it so that they can reach each other using that object. It is also responsible to fire events when new jobs are added or background workers finish their job.

Since it knows a lot about the system, is this type of usage too much responsibility in one place, or is this the correct usage of the pattern?

Answer 1

Sounds better than the alternative... But hey, I married the least ugly sister ;-)

Answer 2

Normally I would use the command pattern for something like that:

1. User clicks the "Foo" button on menu bar, which executes the FooButtonClickedCommand.
2. FooButtonClickedCommand does whatever it's supposed to do, then modifies the view (menu bar, tables, etc) appropriately.

So your commands know about all your view components, but the only thing your view components need to know is which command to execute when a given action is done by the user.

Answer 3

I would use a Passive View which you can read about here.

• You would put each form behind an interface
• Each form would register itself with one or more UI Objects
• The UI Object should be naturally organized, like Setup, Entry, Display, etc. A word processor may only have one UI Object for each document. While a machine controller may have multiple object for each screen.
• The interface are implemented as thin shells passing on events to the UI Objects and exposing presentation controls, drawing surfaces to the UI Object.
• The UIObject then take the input and figures out which command object to execute
• The Command Object will update the model, then tell one or more UI Objects to update the view.
• The UIObjects update the views.

Note that nowhere does anything beyond the UI Interface knows about buttons, check boxes, and the like. You use the Interface to abstract the actual implementation away.

This will give you several advantage. First it will document how your code interacts with the UI, give you a place to implement mock objects to use for automated testing, and finally allow much more latitude in changing the UI.

For example substituting clickable panels instead of command buttons. The form will then just start passing the click events from the panels instead of the button. The form can remain ignorant of the actual command each widget is supposed to do. The UI Object takes care of that.

Answer 4

From your description it sounds like an MVC model. The MVC model is join of Strategy and Observer patterns, in some narrow aspects Mediator can be more suitable replacement for Strategy. So I think you made quite good choice.