Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Author Topic: Question about Nomenclature  (Read 6863 times)
Posts: 2

View Profile Email
« on: April 21, 2008, 08:07:51 »


Together with some colleagues I have been reviewing PureMVC and we have built a test application
using it largely "by the book" (following the rules of thumb etc.) over the last week or so.

While our experience has been generally very positive in terms of obtaining a clean design and
breakdown of responsibilities, we did run into a hump with some of the choice of nomenclature, and what looks to us like significant departure from "standard" GOF Patterns usages.

In particular:

1. PureMVC's "Mediators" look like Adapters for UI components in the simplest case, where a "Mediator" wraps a single UI component.

2. PureMVC's "Proxies" look like Model instances in the simple case where they do not stand in for anything else, or possibly Adapters that hook the Model elements into PureMVC's notification system.

I am sure that my colleagues and I would have found PureMVC significantly easier to pick up if e.g. "Mediator" had been called something like "ViewAdapter" and "Proxy" was "ModelAdapter".  [I understand that these names are not likely to change at this stage!]

So why this choice of nomenclature?

Is it the case that in fully-fledged applications "Mediators" tend to mediate between multiple UI components almost all the time, and that "Proxies" become local proxies for remote data objects (or some-such) most of the time?

Or something else entirely?

* * *

On the positive side, having gotten over the dissonance of the naming conventions, the _consistency_ of names has been great!

Thanks in advance

Dan Prager
Austhink Software
http://bCisive.austhink.com -- Making decisions easier

Global Moderator
Hero Member
Posts: 2871

View Profile WWW Email
« Reply #1 on: April 22, 2008, 10:44:08 »

If you read them carefully, you'll find the facade, adapter, bridge, mediator and proxy patterns all have a lot of similarity and overlap in their roles, responsibilities and collaborations.

These patterns are abstract and can be implemented in many other forms than the ones diagrammed, and often the 'Known Uses' section of a pattern will describe completely different situations from the main examples used to illustrate the pattern. The goal then is to get to the essence of the pattern, which fortunately they were wise enough to do in the opening sentence of each pattern's description.

From Design Patterns:
  • Adapter: "Converts the interface of a class into another interface that Clients expect."
  • Mediator: "Define an object that encapsulates how a set of objects interact."
  • Proxy: "Provide a surrogate or placeholder for another object to control access to it."

Adapter or Mediator?
The PureMVC Mediator is clearly not converting the interface of its view component to another interface.  No other objects in the system manipulate that view component they only communicate with its mediator via Notification, not an interface. 

It is mediating communications between the view component and the rest of the system. It listens to the view component and communicates with the other actors as need be, and visa versa. The first example in GOF is a mediation of communications between various components in a dialog. But Flex and MXML binding work fine to keep the objects in a dialog coordinated. The mediation that the framework requires is between the view component and notification participants.

Adapter or Proxy?
The PureMVC Proxy is not doesn't convert the interface of its data object to another interface, though it could, and this is where the Proxy and Adapter patterns would overlap. But in PureMVC, its primary use is to control access to a particular data object. It often acts as a Remote Proxy, encapsulating the access to a remote object. It can create the data object on demand, deferring the instantiation until the request for the expensive data object is made.

Posts: 2

View Profile Email
« Reply #2 on: April 22, 2008, 03:36:13 »

Hi Cliff

Thanks for the clarifications.  In particular, I can appreciate that I was looking at the mediators at least partly "back-to-front" in terms of what it was mediated, and -- as you point out -- seeing the mismatches by taking narrower interpretations of the GOF patterns.

Very helpful!

Pages: [1]