In a Command, calling methods on Proxies but not Mediators

[jpwrunyan]

Ok, I am anticipating this question coming up in my project:

Why is it ok for a Command to grab a Proxy and call some method directly on that Proxy but the same thing is not allowed for a Mediator?

Ideally, Proxies do their own work, but sometimes I need to control them via a Command (for example, tell a Proxy that it no longer need retrieve data from the server in real-time; tell a Proxy to refresh its data from the server; etc.--it's always for remote data).  From what I have seen so far, it is ok for a Command to grab a Proxy and call some method implemented on that Proxy to accomplish any one of those things.  Correct me if I am wrong, please.

But for a Mediator, it is incorrect to grab its instance and tell it to do something.  Use a notification instead.

Obviously, since Proxies can't respond to Notifications there is no choice but to call a method on the Proxy instance.  But now it begs the question, so why not Mediators, too?  What's good for the goose is good for the gander, right?

Anyway, I think I am missing something here, and since I am going to have to explain this to my co-workers soon, I don't want to sputter when they make this argument.  Or even worse, I don't want to make a mistaken argument.

So again, please, tell me why it is ok for a Command to call methods directly on a Proxy but be forced to do the same via a Notification for a Mediator.  And if my question contains a false assumption, please tell me that, too.

Thanks!

[puremvc]

We are looking to decouple things with the framework. Sending a note is more decoupled than is calling a method, which couples the caller to the called. Mediators by definition are meant to translate messages between view components and the rest of the system. If they expose methods and you call them, you are creating a coupling that makes refactoring more difficult.

On the Proxy side, there is no ability to listen to notes because that is the area where we are most concerned about coupling. We want to achieve a portable model, such that the model classes can be reused in another app (i.e. A desktop version of our web app, perhaps with different use cases). So if the Proxies are listening for notes defined elsewhere in the app, you've tied the model to the app it is a part of.

Also the view and controller regions of the app have no other purpose in life than to present and allow the user to interact with the domain model, so it is understandable that there will be some unavoidable  dependence on the model in those regions.

This is why we send notes to mediators but invoke methods on proxies.

-=Cliff>

[jpwrunyan]

Thanks!  I felt very comfortable explaining the coupling issues with Mediators, but less so regarding Proxies.  Furthermore, if I follow you correctly, when a Command calls a method on the proxy, that makes the Command dependent on the Proxy but not vice-versa.  Keeping the model tier portable at the expense of the control tier's independence.  I think I finally got it.

[puremvc]

Furthermore, if I follow you correctly, when a Command calls a method on the proxy, that makes the Command dependent on the Proxy but not vice-versa.  Keeping the model tier portable at the expense of the control tier's independence.  I think I finally got it.

Correct. A coupling is created when one class 'knows about' (i.e. imports and calls methods on) another class.

With OOP, we always want loose-coupling, but there is the *direction* of coupling to consider. Some directions are more important to make loose than others.

Since the View and Controller tiers have no purpose but to expose the Model tier to user interaction, it is acceptable to have them know a considerable amount about the Model. Of course, that doesn't mean Proxies should make everything public. They should encapsulate as much as they can and expose a rational set of methods for interaction that don't presume a working knowledge of the internals of the class.

However since you often want to reuse part or all of the Model tier in other applications, coupling of the Model tier to the View and Controller tier should be considered taboo. That is, Proxies shouldn't make any dependencies or assumptions about the View and Controller tiers.

-=Cliff>

[jpwrunyan]

Thanks again Cliff for the reply.  I know this is all basic MVC theory stuff but I have never used MVC (outside of one tutorial) until PureMVC.  I appreciate the crash-course education you provide!