Un-Mapping Mapped Network Drives Andrew Coates - dFPUG-Portal

Best Practices FoxTalk
Seeing Patterns: The Mediator
Jefferey A. Donnici
This month’s column continues the series that looks at some
common design patterns and how they can be found and
used within our Visual FoxPro applications. The pattern
discussed this month is the Mediator pattern, which allows a
single object to handle the interaction between a set of other
objects. In doing so, the set of mediated objects is less
coupled to one another and can be extended or varied
independently. To illustrate the Mediator pattern in action,
two very different examples are given.
WITH the last Best Practices column, I began a new
series called “Seeing Patterns.” For those who
missed that column (for shame!), the intent
behind this series is to discuss the real-world use of some
common design patterns, using VFP examples for
illustration. If you aren’t already familiar with the concept
of object-oriented design patterns, I encourage you to
look through the last column for some references and a
discussion that provides an introduction to the ideas
behind design patterns. Specifically, you should make
sure to get a copy of Design Patterns: Elements of Reusable
Object-Oriented Software by E. Gamma, R. Helm, R.
Johnson, and J. Vlissides (Addison-Wesley, ISBN 0-201-
63361-2). This is the most popular of all the patternsrelated
books, and any developer working with an objectoriented
language should have it.
With the introduction to design patterns out of the
way, I can dive right into this month’s discussion of the
Mediator pattern. This column provides an introduction
to the Mediator and, more importantly, some real-life VFP
examples. Hopefully, the VFP-centric approach to this
discussion will help you learn to “see” this pattern in
your own work, thereby making it easier to pull it from
your “toolbox” when solving a design problem in the
future. Remember, however, that object-oriented design
patterns represent another layer of abstraction above the
design process. As such, the patterns themselves aren’t
specific to any one programming language or design tool.
Why the Mediator?
The purpose of the Mediator pattern is to provide a
central point for interaction between a set of similar
objects. By having all interaction in a set of objects go
through one portion of the component or subsystem, the
dependencies and coupling between the objects in that set
are reduced. As explained in Design Patterns, the intent of
6 FoxTalk December 1998
http://www.pinpub.com
6.0
the Mediator is to “define an object that encapsulates how
a set of objects interact. Mediator promotes loose coupling
by keeping objects from referring to each other explicitly,
and it lets you vary their interaction accordingly.”
A good object-oriented design typically has a large
number of classes in it, simply because behavior and data
are spread out among the classes to provide cohesion. The
more a system is comprised of a set of highly specialized
“pieces,” all working together to provide larger
functionality, the more those pieces can be reused. On the
extreme opposite end of the spectrum, a few large classes
that perform several different functions apiece aren’t
typically reusable in a different application context.
The flip side of this design principle, however, is that
the relationships between (or “the coupling of”) all those
objects brings with it a higher learning curve for the
designer and programmer, as well as the potential for
reduced reusability. If each object in a subsystem must
know the programmatic interface for all the other objects
in the subsystem, then the overall reusability of every
object suffers. So, while a large number of objects in a
system typically means that they’re inherently more
cohesive, each new object in the system has the potential
to increase the number of dependencies exponentially.
The Mediator provides a solution to this problem by
acting as a central point of contact for all those intrasystem
communications. Think of the Mediator as a
“traffic cop” that makes sure everyone gets through the
intersection like they should, without anybody having to
get out of their car and talk to another driver. As long as
all the “mediatees” (the cars and drivers) are being
coordinated by the “mediator” (the traffic cop), there isn’t
any need for the objects (or grumpy drivers) to interact
with one another (see Figure 1).
The benefits of this approach are numerous. The
decoupling of the “mediatees,” called “colleagues” in
Design Patterns, has been mentioned already, but there are
others as well. For example, your class hierarchies can be
less deep because the need to subclass is reduced when
using a Mediator. The Mediator defines the interaction
between the pieces of the system, so only the Mediator
needs to be subclassed when the nature of the
relationships changes. Each of the classes themselves
remains the same, with the “translation” between them
occurring within the Mediator.
Also, the Mediator simplifies the nature of the