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

Show Posts

| * |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / General Discussion / Question about Nomenclature on: April 21, 2008, 08:07:51
Hello

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


Pages: [1]