Manual Mediators

mike.cann's Avatar

mike.cann

02 May, 2014 12:49 AM

Hi,

Im using Strange IoC (Unity version of Robotlegs) but the principles are the same. I was wondering, can you think of a reason why "Manual Mediation" is a bad idea so long as you are using interfaces?

By manual mediation I mean, for example in a mediator doing something like "injector.getInstance(IMyCommand)"; to get a command instance rather than firing off an event or a signal which will spawn and instance of a command. Obviously you want to keep a nice separation between logic and keep a single place for mappings (the context) but as far as I see it, so long as you are using an interface for your command and mapping that interface to a command implementation in the context you are still keeping your concerns separated.

The reason im doing this is because I want to have a command that returns something and passing in a return reference into an event or signal param just seems messy.

Mike

  1. 1 Posted by mike.cann on 02 May, 2014 01:00 AM

    mike.cann's Avatar

    Whoops, I guess this should be called "Manual Commanding" not "Manual Mediation" :P

  2. Support Staff 2 Posted by Ondina D.F. on 03 May, 2014 07:25 AM

    Ondina D.F.'s Avatar

    Sorry Michael, I'm on vacation. I've notified Shaun and creynders about your question. You might get a response from them.

  3. Support Staff 3 Posted by creynders on 03 May, 2014 09:49 AM

    creynders's Avatar

    Hi Michael,

    I'd definitely recommend against retrieving the command into the mediator, since it gives the mediator too much knowledge about the system. The idea is that a mediator shouldn't know whether its' a command, service or whatever that responds to its events. This gives the biggest amount of freedom. Requirements change and maybe one day something else needs to happen before that command can do its job, which means that either you'll be rewriting your mediator to execute multiple commands or you'll let the single command do more stuff. But if it does more stuff chances are it muddies the contract the command has fulfilled by implementing a specific interface.
    Another thing, now the command responds in a sync manner, but what if the new requirement means it needs to do an async operation?
    The separation of concerns is not about getting things done now, but about keeping your code scalable and maintainable. Though I agree with you it's far easier to have some kind of reqres pattern, this scales badly and also injects too much low-level detail into the mediator, whose job is to mediate: translate system data and events to view data and events and vice versa.

    A solution would be to trigger an event from the mediator and pass some kind of completion event instance as a payload, then the command does its job and returns the result by triggering the completion event and passing the results as its payload.

  4. 4 Posted by mike.cann on 04 May, 2014 03:02 AM

    mike.cann's Avatar

    Hi Creynders,

    Thank you for taking the time to get back to me.

    You are probably quite right though passing in a return task into the Command seems messy.

    Ill have a think on this some more.

    Cheers,
    Mike

  5. Ondina D.F. closed this discussion on 02 Jul, 2014 07:15 AM.

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

Keyboard shortcuts

Generic

? 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