Composite mediators (bad practice?)

xantrus's Avatar


03 Aug, 2011 09:12 AM

Is it a bad practice to have composite mediators for my composite views?

I am having a situation, in which I have composite views consisting of smaller components, which are reused across the component, As a result, every view shares some functionality with the others, but in general is quite unique. Thus, I do not really see mediator inheritance as an option. I would like to have something like concrete, or composite mediators, and generic mediators. The generic ones will expect views only based on interface contracts.

Every composite mediator will take care of keeping a collection of generic mediators, supplying them with a view, and managing their onRegister and onRemove methods (simple composition). Generic mediators therefore will not even need injection, because they will be supplied by the concrete ones. Only the composite ones will be injected by the context.

Unfortunately, this approach smells a bit like coupling to me. In order for the composite mediators to reflect the uniqueness of the composite view, they have to know what to expect from each view. However, if the view changes, i will have to redesign the mediator as will, right? On the other hand, I think that I have to redesign a mediator anyway, if I change a view, but still ..

I am open to ideas and suggestions

  1. 1 Posted by Stray on 03 Aug, 2011 09:44 AM

    Stray's Avatar

    Hi Xantrus,

    I think you're almost there with this - if you add some interfaces to your composite views then you can use a factory to automatically determine which mediators to create for this view. This is called "covariant mediation" - guyinthechair recently made a utility for it - which you can find here:

    I haven't tried the util, but it might give you some clues as to the best approach, or you might be able to use his util directly.

    And, as you say, changing the mediator when the view changes is hard to avoid. I'd say some view-mediator coupling is unavoidable - the key thing is to keep it to the api and events domain.



  2. Ondina D.F. closed this discussion on 02 Nov, 2011 06:00 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac