i

Session
Using Software Design Patterns

Bill Anderson
billa@andersonfiles.com

Overview
One of the hallmarks of a successful application is the adaptability to
change to new and updated requirements. This flexibility isn’t inherent –
it should be planned in the application’s design phase. Using Software
Design Patterns in your development will provide the foundation for
handling these unexpected requirements. This session presents many
useful design patterns that can lead to more flexible applications.

Software Patterns – A Definition

In reference to construction patterns, Christopher Alexander states, “Each

pattern describes a problem which occurs over and over again in our
environment, and then describes the core of the solution to that problem,
in such a way that you can use this solution a million times over, without
ever doing it the same way twice.” Mr. Alexander was referring to physical
spaces and objects – windows, doors, walls and the like. While software
design patterns are expressed in terms of objects, methods and
interfaces, the generality is very similar. Patterns are a solution to a
problem in a context.
Software design patterns solve specific design problems and make object
oriented designs more flexible, elegant and adaptable to changing
requirements.
Quoting from the book Design Patterns – Elements of Reusable Object-
Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and
Using Software Design Patterns Southwest Fox 2006
© 2006 Bill Anderson (OOP)
John Vlissides (if you ever hear about the “Gang of Four” or see the initials
GoF, this is the “gang”.) A pattern has four essential elements:

1. The pattern name is a handle we can use to describe a design

problem; its solutions and consequences in a word or two.
2. The problem describes when to apply the pattern. It explains
the problem and its context.
3. The solution describes the elements that make up the design,
their relationships, responsibilities, and collaborations. The
solution doesn’t describe a particular concrete design or
implementation, because a pattern is like a template that can
be applied in many different situations.
4. The consequences are the results and trade-offs of applying
the pattern.

In essence a software design pattern 1) has a name 2) has a reason to

exist 3) is defined and 4) has a (beneficial) result.

Familiarity with Software Patterns

You’re already very familiar with software patterns. Let’s demonstrate

your familiarity with some examples…
What object(s) would you use to handle unlimited amounts of text? An
edit box would be a good choice.
What object(s) would you use to handle a sequential range of numbers? A
spinner comes to mind…
What object(s) would you use to handle a static list of items? Well, we
have several objects available to us to handle a static list of items. Which
object is truly appropriate will depend on our requirements (can the list
be updated, available room on the form, etc.), but there are several
appropriate selections. Obvious and clear choices are list boxes and
combo boxes. In VFP 8, grids can be made to act like list boxes. In VFP 9,
the textbox class has been enhanced via the AutoComplete property to
automatically store and suggest values. But we can certainly rule out
certain controls such as the check box, command button, timers,
separators and others.
See what I mean? You’re already very familiar in applying generic
solutions to your specific application development issues.
Using the edit box control as an example, you implicitly know the context
by which the control is used and when it isn’t. Whether or not the edit box
control is read only or not, or the specific name of the control source used
to bind the edit box to a field or the height of the edit box – those issues
are implementation details. You’re familiar with the control, how to use it
and when it’s appropriate to use such a control.

Southwest Fox 2006 Using Software Design Patterns

(OOP) © 2006 Bill Anderson
An edit box (like other base controls in VFP and other languages) can be
considered a control used to handle an application design problem. It’s
not a software design pattern, but it’s a pattern nonetheless.
For contrast, let’s apply the edit box control to the GoF software design
pattern definition:

1) Name – Edit Box.

2) Problem to solve – Providing an easy to use control for handling
unlimited amounts of text.
3) Design, relationships, responsibilities, collaborations – this isn’t
applicable to controls. Pattern is like a template – an edit box
certainly is a template. We supply the size, control source and
other behaviors to apply it to a specific situation.
4) Consequences, results – We can handle large amounts of text but
the control takes up a lot of room compared to the size of other
controls.

To repeat, you’re familiar with patterns. Let’s see how software design
patterns are used to solve specific design problems.

Using Software Design Patterns Southwest Fox 2006

© 2006 Bill Anderson (OOP)
Bridge Pattern

Definition: Decouple an abstraction from the implementation so

the two can vary independently.
Heuristic: The definition says it all. Separate a class’s
abstraction from its implementation by making each a separate
class. Defer implementation details to these classes. Avoid “God”
objects.

The Bridge Pattern is the most fundamental of all design patterns.

We’ll illustrate the Bridge Pattern with a simple example. Here’s a typical
line of VFP code:

lnResult = MESSAGEBOX([Are you sure you want to delete this record?], ;

4 + 32, [11th European Visual FoxPro DevCon])

What could be wrong with this line of code? We’ll look this line with a little
more detail…

Delivery Mechanism Message

(Implementation) (Abstraction)
 
lnResult = MESSAGEBOX([Are you sure you want to delete this record?], ;
4 + 32, [11th European Visual FoxPro DevCon])

We’re combining the method of delivery with the message being

delivered. In essence, we are coupling the “envelope” (the delivery
mechanism) with the “letter” (the actual message) and “mailing”
(displaying the message) it all in one command. Later on, you may
determine that some of your users prefer the old style WAIT WINDOW or
dialogs with different styles (a different envelope). Or perhaps your
application will be used as an in-process DLL automation server where no
user interface is allowed (Don’t deliver the mail).
The solution is to build a message handler object to deal with the
implementation issues. Assuming for the moment that we’ve instantiated
an object property in our class called oMessageHandler (or the act of
referencing oMessageHandler triggers the assign method of this object
property, instantiating the object for us) we can write the example line of
code in this fashion:

Southwest Fox 2006 Using Software Design Patterns

(OOP) © 2006 Bill Anderson
 Delivery Mechanism Message
(Implementation) (Abstraction)
 
lnResult = THIS.oMessageHandler.Display([Are you sure you want to delete
this record?])

The object oMessageHandler acts as a bridge between the

implementation and the abstraction.

Bridge Types

Reference Bridge – The above example is defined as a reference bridge.

The interface object has a property which contains a reference to the
implementation object.

Multiple Bridge – A multiple bridge is a reference bridge that uses an

array property to hold implementation object references.
An example of a multiple bridge within Visual FoxPro is the SetAll method
of a container. Given a container object named oContainer and the
following command is issued

oContainer.SetAll([Tag], [Test])

Internally Visual FoxPro does something like this:

FOR EACH loObject in THIS.Objects

loObject.SetProperty([Tag], [Test])
ENDFOR

Aggregation Bridge – An aggregation bridge is an implementation

object that is placed on a container object at design time or at run time
via the AddObject method.
To repeat, the bridge pattern is the most basic of all design patterns. In
fact, the core of many design patterns to follow incorporates this basic
pattern.

Using Software Design Patterns Southwest Fox 2006

© 2006 Bill Anderson (OOP)
Decorator (Wrapper) Pattern
Definition: Attach additional responsibilities to an object
dynamically. Decorators provide a flexible alternative to
subclassing for extending functionality.
Heuristic: Subclass all “black box” objects such as the Visual
FoxPro base classes (or if you’re using a VFP based framework,
subclass the framework classes) and ActiveX controls.
If you’ve subclassed a Visual FoxPro control, then you’re familiar with the
Decorator pattern.
The goal of the Decorator pattern is rather straightforward to understand
– make a class that provides the same methods and properties as the
object being subclassed. This gives you the ability to augment, override or
suppress the behavior of the object being subclassed. Visual FoxPro does
this automatically for all VFP base classes and ActiveX controls so
decorating is easy.
Using the IMPLEMENTS clause of the DEFINE CLASS statement is in effect
a decorator around a COM component.
Decorators can also be used for “white box” objects as well to modify
behavior as needed in a controlled fashion.
Decorators can easily be extended beyond software management. You
can use a function to decorate a VFP function or command.
Example: Placing an unmodified Microsoft Web Browser control (Internet
Explorer) onto a Visual FoxPro form simply will not run correctly. A
NODEFAULT statement must be placed in the Refresh method of the Web
Browser control. Simply subclass the Microsoft Web Browser control,
decorate the Refresh method with a NODEFAULT statement and use this
decorated subclass in your forms and classes.

Southwest Fox 2006 Using Software Design Patterns

(OOP) © 2006 Bill Anderson
Adapter Pattern
Definition: Convert the interface of a class into another
interface clients expect. Adapter lets classes work together that
couldn’t otherwise because of incompatible interfaces.
Heuristic: Use an adapter pattern to translate a new or updated
interface to an established interface. In other words, make a class
look like another class.

Whereas a Decorator pattern is used modify the behavior of a particular

class, the Adapter pattern does not modify object behavior. The Adapter
pattern is used to only modify an interface to the object.
Let’s say that we’re using a class named A. We make calls to the methods
in class A in our application. Later on, we decide to replace the class
named A with a class named B. However, some of the method names are
different. What do we do?
One method is to go through the application and rip out/replace all of the
calls to methods within class A with similar calls to class B. This plan has
several consequences: (1) There may not be an easy one to one
correspondence with method names (2) If you later replace class B with
class C, the same issues arise.
The solution is to use a subclass of B (let’s call it BB for now) and add
every method in class A that isn’t in B (Note that even if class A has a
same method name as B, that does not necessarily imply that these
methods perform the exact same function). By definition, the class named
BB contains all the method names of both A and B. Now map the “A”
method names to one or more of the “B” method names. If there’s no
matching method(s) in B for a method, then you’ll need to write your own
method.
If this appears to you be an extension of the bridge pattern, it is. The
subclass BB is a bridge between the methods of class A and class B.
Example: Let’s say you’re using a subclass of the Microsoft Web Browser
control in your application. Later on, you decide to replace this ActiveX
control with a Web Browser control from a competing company. Use the
Adapter pattern to subclass this new control and make it look like the
interface to Microsoft Web Browser control.

Using Software Design Patterns Southwest Fox 2006

© 2006 Bill Anderson (OOP)
Template Method
Definition: Define the skeleton of an algorithm in an operation,
deferring some steps to subclasses. Template Method lets
subclasses redefine certain steps of an algorithm without
changing the algorithm’s structure.
Heuristic: Define a common sequence of events via methods of
a template class, leaving the implementation of these methods to
subclasses.

Template patterns are often used by third party frameworks as

placeholders for you, the developer, to add additional behavior to address
a specific scenario. Template patterns will contain abstract operation
methods (which should be coded in the subclasses) and should contain
hook operations (which could be coded in the subclass) which serve as
empty placeholder methods.
Example: Let’s build a skeleton template class to export a file. The
process would look something like this:

Function Export
WITH THIS
LOCAL llExported
llExported = .f.
.cExportFile = .GetFileToExport()
IF .OpenFileToExport(.cExportFile) && abstract operation method
IF .BeforeExportFile(.cExportFile) && hook operation
llExported = ExportFile(.cExportFile) && abstract operation method
.AfterExportFile(.cExportFile, llExported) && hook operation
ENDIF .BeforeExportFile(.cExportFile)
ENDIF .OpenFileToExport(.cExportFile)
.CloseFileToExport(.cExportFile)
IF NOT llExported
.WriteError()
ENDIF NOT llExported
RETURN llExported
ENDWITH

In this example the OpenFileToExport, BeforeExportFile, AfterExportFile

and ExportFile are empty methods in this template class.
OpenFileToExport and ExportFile must be coded in the subclass, or no file
will be exported. The BeforeExportFile and AfterExportFile methods are

Southwest Fox 2006 Using Software Design Patterns

(OOP) © 2006 Bill Anderson
empty methods that could be used by the subclass to provide additional
capabilities.

Iterator Pattern
Definition: Provide a way to access the elements of an
aggregate object sequentially without exposing its underlying
representation.
Heuristic: The mechanism of traversing and accessing a
common set of objects should be separated from the objects
being traversed.

If you’ve ever traversed an array, then you’re familiar with the concepts
behind the Iterator pattern.

The Collection base class was added to Visual FoxPro 8. This base class
provides the basic functionality of the Iterator pattern. The collection base
class is a container object whose contained members are referenced by
number or by a passed index to the Item method. Members can be added
via the Add method and removed via the Remove method. Members can
be sorted as needed through the KeySort method property and traversed
via a FOR or FOR EACH loop.
Note that the objects being referenced have no knowledge of being
contained within a collection – even if the contained members are also
collections!

Using Software Design Patterns Southwest Fox 2006

© 2006 Bill Anderson (OOP)
Observer Pattern
Definition: Define a one-to-many dependency between objects
so that when one object changes state, all its dependents are
notified and updated automatically.
Heuristic: Use an observer pattern to separate state
management from the objects being managed.

The Observer pattern has characteristics of both the Bridge and the
Iterator patterns. State management is abstracted from the objects that
react to changes in state management so the two can vary
independently. Once such a state management change occurs, the
Observer object iterates through the collected objects and passes the
message to the managed objects.
There are two different types of Observers, Active (also known as Voyeur)
and Passive (also known as Publish-Subscribe). The difference can be
shown the following task: Given a form that uses a private data session
and contains Save and Cancel buttons, we only want these buttons to be
enabled if the underlyingrecord has been changed.
Assume that the Save and Cancel buttons are members of an Iterator
object (by definition a collection) that should react to the dirtied buffer.
Voyeur Object: Use a timer. At each interval this global timer object will
grab a reference to the active form, determine the form’s data session,
keep track of the current buffer status and determine if the status has
changed. If the state has changed, pass the state change message to the
relevant Iterator object, enabling or disabling the controls.
Note that the voyeur (Timer) has no knowledge of the objects reacting to
the state change and does not reside on the form.
Publish/Subscribe: Objects that can dirty the buffer (textboxes, list boxes,
etc.) have a hook method in the KeyPress event that calls a global
KeyPress handler object. Every time a key is pressed, control passes to
the global KeyPress handler. The buffer is checked. If the state has
changed, pass the state change message to the relevant Iterator object,
enabling or disabling the controls.
Note that the publisher (KeyPress handler) has no knowledge of the
objects reacting to the state change and does not reside on the form.
This (somewhat artificial) example shoes the difference between an active
and passive Observer object.
The SuperClass toolbar is a classic example of the Voyeur pattern.

Southwest Fox 2006 Using Software Design Patterns

(OOP) © 2006 Bill Anderson
Mediator Pattern
Definition: 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 independently.
Heuristic: Use the Mediator Pattern to manage complex
protocols through a common communication point.

The Mediator Pattern is used when a central object can be used to handle
event notification. The Mediator is a form of a Passive Observer; it acts as
a communication hub that serves to promote loose coupling of objects.
Example: One of the most common examples of the Mediator pattern is
an object to manage all the open forms within an application. To populate
the forms manager, all forms add references to themselves to the forms
manager upon instantiation. When a form is destroyed, a call is made to
the forms manager to remove the reference.
Assume that we have several open forms. If a message is received to
close all the open form in the application (usually sent by a Close All
menu bar), the Forms manager can iterate through the references and
close all of the open forms.

Using Software Design Patterns Southwest Fox 2006

© 2006 Bill Anderson (OOP)
Memento Pattern

Definition: Without violating encapsulation, capture and

externalize an object’s internal state so that the object can be
restored to the state later.
Heuristic: Use the Memento pattern for “housekeeping” chores
to save and restore the Visual FoxPro environment.
Have you ever heard of the camping/hiking proverb “Take pictures, leave
footprints.”? The clear meaning behind this simple adage is to leave the
environment in the same state in which you arrived.
The Memento pattern is very useful in tending to our Visual FoxPro
housekeeping chores such as maintaining work areas, SET or ON settings,
etc. Simply build an object that holds the setting and change the value as
necessary. When the routine ends, release the object and restore the
setting.
Example: The class code below saves and restores a work area. Use this
code to store the current work area and optionally move to another alias.
When released, the work area is restored.

DEFINE CLASS WorkAreaMemento AS Relation

PROTECTED nOldWorkArea
nOldWorkArea = []
Name = [WorkAreaMemento]
PROCEDURE Init
LPARAMETERS tcAlias
THIS.nOldWorkArea = SELECT()
IF NOT EMPTY(tcAlias)
SELECT (tcAlias)
ENDIF NOT EMPTY(tcAlias)
RETURN DODEFAULT()
ENDPROC
PROCEDURE Destroy
SELECT (THIS.nOldWorkArea)
RETURN DODEFAULT()
ENDPROC
ENDDEFINE

Southwest Fox 2006 Using Software Design Patterns

(OOP) © 2006 Bill Anderson
Chain of Responsibility Pattern

Definition: Avoid coupling the sender of a request to its

receiver by giving more than one object a chance to handle the
request. Chain the receiving objects and pass the request along
the chain until an object handles it.
Heuristic: Use the Chain of Responsibility Pattern when you
would like more than one object to handle a request or the set of
object that can handle a request should be specified dynamically.
The first sentence in the help for the DO CASE…ENDCASE command reads
“Executes the first set of commands whose conditional expression
evaluates to true (.T.)”. Imagine for the moment if the command worked
like this: “Executes all commands whose conditional expression evaluates
to true (.T.)” – then you would have the programmatic equivalent of the
Chain of Responsibility pattern.
The Chain of Responsibility pattern decouples the sender of a message
from the recipient by giving multiple objects a shot to handle the
message (There’s that pesky Bridge Pattern again…). While the
implication is that only one object in the chain can handle the message, in
fact multiple objects can respond to the request. Or have no object handle
the request, for that matter. The idea behind the Chain of Responsibility
pattern is to separate the decisions among multiple objects (don’t contain
all the logic in one object), allowing for a more flexible design strategy.
This pattern is most easily seen within established hierarchies. The
handling of the Visual FoxPro Error Event within a containership hierarchy
is a classic example of the Chain of Responsibility Pattern. If an error is
generated within an object, the object’s Error Event is called. If it isn’t
fully handled by the object’s Error Event, the call is placed to the Error
Event of the parent class. If it isn’t handled by this container, its parent
class Error Event is called…until the Form is reached. If the Form’s Error
Event doesn’t handle the message, the program associated with ON
ERROR is called.
The implied hierarchy available within the Visual FoxPro inheritance
model is another example of this pattern. The DODEFAULT/NODEFAULT
keywords can be used to control program flow through a hierarchy of
subclasses.
Note that one of the downsides of this pattern is that managing object
references can get tricky and debugging could be more complicated. But
the upside of a more flexible design more than outweighs the
complications.

Using Software Design Patterns Southwest Fox 2006

© 2006 Bill Anderson (OOP)
Abstract Factory Pattern
Definition: Provide an interface for creating families of related
or dependent objects without specifying their concrete classes.
Heuristic: Avoid the explicit use of CREATEOBJECT or
NEWOBJECT functions. Let the Abstract Factory Pattern handle
the object composition.

The speed of finding a record makes Visual FoxPro applications an ideal

candidate for using the Abstract Factory pattern.
Assume we’re coding within a method of an object and we need to create
a pink widget object. We might do something like this:

loPinkWidget = CREATEOBJECT([myPinkWidget])

In this example myPinkWidget is the class name of the pink widget. Using
the Abstract Factory, we would code it something like this:

loPinkWidget = oFactory.GetClass([PinkWidget])

In this example, class instantiation is deferred to the oFactory object. The

GetClass method receives the abstract class name PinkWidget. The
GetClass method uses this token (PinkWidget) as a value to SEEK() within
a table. If a match is made, the class name is returned – myPinkWidget in
our first example. This is the concrete class name. The object is then
created using this concrete class and is returned.
In practice, the table used to hold the concrete class references becomes
an object dictionary – a common reference point for referring to types of
objects. If you’re ever used a data dictionary then the advantages of an
object dictionary are clear. There’s only one point of maintenance.
If you get a better, faster, or slicker pink widget (let’s call it
myBetterPinkWidget), simply replace the old class name with the new
class name.

Southwest Fox 2006 Using Software Design Patterns

(OOP) © 2006 Bill Anderson
Conclusion
Using Software Design Patterns assist in keeping an application as flexible
as possible. As the requirements change, these and other Software
Design Patterns provide hooks for adding functionality as required. The
maintenance burden is mitigated. More importantly, the time used to
implement these patterns is usually much less than the maintenance
burden over the life of the application.

As a guideline for your software development, here’s the list of heuristics:

1) Separate a class’s abstraction from its implementation by making each
a separate class. Defer implementation details to these classes. Avoid
“God” objects.
2) Subclass all “black box” objects such as the Visual FoxPro base classes
(or if you’re using a VFP based framework, subclass the framework
classes) and ActiveX controls.
3) Use an adapter pattern to translate a new or updated interface to an
established interface. In other words, make a class look like another class.
4) Define a common sequence of events via methods of a template class,
leaving the implementation of these methods to subclasses.
5) The mechanism of traversing and accessing a common set of objects
should be separated from the objects being traversed.
6) Use an observer pattern to separate state management from the
objects being managed.
7) Use the Mediator Pattern to manage complex protocols through a
common communication point.
8) Use the Memento pattern for “housekeeping” chores to save and
restore the Visual FoxPro environment.
9) Use the Chain of Responsibility Pattern when you would like more than
one object to handle a request or the set of object that can handle a
request should be specified dynamically.
10) Avoid the explicit use of CREATEOBJECT or NEWOBJECT functions. Let
the Abstract Factory Pattern handle the object composition.

Using Software Design Patterns Southwest Fox 2006

© 2006 Bill Anderson (OOP)
Resources
Design Patterns Books
Coplien, J. (1992), Advanced C++ Programming Styles and Idioms,
Addison Wesley, Reading, MA, ISBN 0201548550.
Gamma, E., Helm, R., Johnson, R, and Vlissides, J. (1994), Design Patterns,
Elements of Object Oriented Software, Addison Wesley, Reading, MA, ISBN
0201633612.
Coad, P, North, D, and Mayfield, M (1995), Object Models: Strategies,
Patterns, and Applications, Prentice Hall, Englewood Cliffs, NJ, ISBN
0131086146.
Coplien, J, and Schmidt, D (1995), Pattern Languages of Program Design,
Addison Wesley, Reading, MA, ISBN 0201607344.
Hay, David (1995), Data Model Patterns: Conventions of Thought, Dorset
House, New York, NY, ISBN 0932633293.
Pree, W (1995), Design Patterns for Object Oriented Development,
Addison Wesley, Reading, MA, ISBN 0201422948.
Buschman, F et al (1996), A System of Patterns, John Wiley & Sons, West
Sussex, England, ISBN 0471958697.
Fowler, Martin (1996), Analysis Patterns- Reusable Object Models.,
Addison Wesley, Reading, MA, ISBN 0201895420.
Vlissides, Coplien, Kerth (1996), Pattern Languages of Program Design 2,
Addison-Wesley?, Reading, MA, ISBN 0201895277.
Mowbray, Thomas (1997), Corba Design Patterns, Wiley, ISBN
0471158828.
Brown, William J. , Malveau, Raphael C. , Hays, W, III McCormick?, Brown,
William H., Mowbray, Thomas J. (1998), AntiPatterns: Refactoring
Software, Architectures, and Projects in Crisis, John Wiley & Sons, ISBN
0471197130.
Grand, Mark (1998), Patterns in Java, Volume 1: A Catalog of Reusable
Design Patterns Illustrated with UML, John Wiley & Sons, New York, NY,
ISBN 0471258393.
Martin, R et al (1998), Pattern Languages of Program Design 3, Addison
Wesley, Reading, MA, ISBN 0201310112.
Vlissides, John (1998), Pattern Hatching, Addison-Wesley?, ISBN
0201432935.

Abstract Factory
http://fox.wikis.com/wc.dll?Wiki~AbstractFactory
http://download.microsoft.com/download/vfox60/Install/6.0/W9X2K/EN-
US/Oakleaf.zip (code sample)
http://www.dofactory.com/Patterns/PatternAbstract.aspx
http://c2.com/cgi/wiki?AbstractFactoryPattern
FoxTalk, March 2002, Andy Kramek and Marcia Akins, The Kit Box: As a
Matter of Fact—ory

Southwest Fox 2006 Using Software Design Patterns

(OOP) © 2006 Bill Anderson
Adapter Pattern
http://fox.wikis.com/wc.dll?Wiki~AdapterPattern
http://www.dofactory.com/Patterns/PatternAdapter.aspx
http://c2.com/cgi/wiki?AdapterPattern
FoxTalk, July 1999, Jeffrey Donnici, Best Practices: Seeing Patterns: The
Adapter
FoxTalk, September 2002, Andy Kramek and Marcia Akins, What’s in a
name?
Bridge Pattern
http://fox.wikis.com/wc.dll?Wiki~BridgePattern
http://www.stevenblack.com/PTN-Bridge.asp
http://www.dofactory.com/Patterns/PatternBridge.aspx
http://c2.com/cgi/wiki?BridgePattern
FoxTalk, March 1996, Steven Black, Extend and Adapt Your Classes with
Bridges
FoxPro Advisor, March 1996, Yair Alan Griver, Use Patterns to Increase
Reuse and Flexibility
FoxTalk, November 1998, Jeffrey Donnici, Best Practices: Seeing Patterns:
The Bridge
Chain of Responsibility
http://fox.wikis.com/wc.dll?Wiki~ChainOfResponsibility
http://www.dofactory.com/Patterns/PatternChain.aspx
http://c2.com/cgi/wiki?ChainOfResponsibilityPattern
FoxTalk, April 1999, Jeffrey Donnici, Best Practices: Seeing Patterns: Chain
of Responsibility
FoxPro Advisor, December 2001, Rick Hodder, Chain of Responsibility
Foxtalk 2.0, October 2004, Lauren Clarke and Randy Pearson, Parsing
Power Tools, Part 4
Command Pattern
http://www.dofactory.com/Patterns/PatternCommand.aspx
http://c2.com/cgi/wiki?CommandPattern
FoxTalk, November 1998, Jeffrey Donnici, Best Practices: Seeing Patterns:
The Command

Using Software Design Patterns Southwest Fox 2006

© 2006 Bill Anderson (OOP)
Composite Pattern
http://www.dofactory.com/Patterns/PatternComposite.aspx
http://c2.com/cgi/wiki?CompositePattern
FoxTalk, November 1998, Jeffrey Donnici, Best Practices: Seeing Patterns:
The Composite
FoxPro Advisor, January 2002, Rick Hodder, Composite Pattern
Decorator Pattern
http://fox.wikis.com/wc.dll?Wiki~DecoratorPattern
http://www.stevenblack.com/PTN-Decorator.asp
http://fox.wikis.com/wc.dll?Wiki~DecoratingWithTHIS_ACCESS
http://www.dofactory.com/Patterns/PatternDecorator.aspx
http://c2.com/cgi/wiki?DecoratorPattern
FoxTalk, July 1996, Steven Black: Design Patterns: Wrappers
FoxPro Advisor, May 1998, Yair Alan Griver, Enhance Existing Code with
the Decorator
Factory Method
http://www.dofactory.com/Patterns/PatternFactory.aspx
http://c2.com/cgi/wiki?FactoryMethodPattern
FoxTalk, January 2000, Jeffrey Donnici, Best Practices: Seeing Patterns:
The Factory
Hook Operation
http://fox.wikis.com/wc.dll?Wiki~HookOperation
http://www.stevenblack.com/PTN-Hook%20Operations.asp
Iterator Pattern
http://fox.wikis.com/wc.dll?Wiki~IteratorPatternFromText
http://www.dofactory.com/Patterns/PatternIterator.aspx
http://c2.com/cgi/wiki?IteratorPattern
FoxTalk, June 1999, Steven Jeffrey Donnici, Best Practices: Seeing
Patterns: The Iterator
FoxPro Advisor, October 2001, Rick Hodder, The Iterator Pattern Makes
Coding Easier
Layers
http://www.stevenblack.com/PTN-Layers.asp

Southwest Fox 2006 Using Software Design Patterns

(OOP) © 2006 Bill Anderson
Mediator Pattern
http://www.stevenblack.com/PTN-Mediator.ASP
http://fox.wikis.com/wc.dll?Wiki~MediatorPatternFromText
http://fox.wikis.com/wc.dll?Wiki~EasyMediator
http://www.dofactory.com/Patterns/PatternMediator.aspx
http://c2.com/cgi/wiki?MediatorPattern
FoxPro Advisor, April 1998, Y Alan Griver, Design Patterns, Observers and
Mediators
FoxTalk, December 1998, Jeffrey Donnici, Best Practices: Seeing Patterns:
The Mediator
Memento Pattern
http://www.dofactory.com/Patterns/PatternMemento.aspx
http://c2.com/cgi/wiki?MementoPattern
FoxTalk, May 1998, Barbara Peisch and Paul Maskens, Kit Box: Saving and
Restoring Objects
FoxPro Advisor, November 2001, Rick Hodder, Strategy and Memento
Observer Pattern
http://fox.wikis.com/wc.dll?Wiki~ObserverPattern
http://fox.wikis.com/wc.dll?Wiki~ObserverPatternExample
http://fox.wikis.com/wc.dll?Wiki~ObserverPatternFromText
http://www.dofactory.com/Patterns/PatternObserver.aspx
http://c2.com/cgi/wiki?ObserverPattern
FoxTalk, April 1996, Steven Black, Design Patterns: Abstract one-to-many
Relationships with Observer
FoxPro Advisor, April 1998, Y Alan Griver, Design Patterns, Observers and
Mediators
FoxTalk, January 1999, Jeffrey Donnici, Best Practices: Seeing Patterns:
The Observer
Singleton Pattern
http://www.dofactory.com/Patterns/PatternSingleton.aspx
http://c2.com/cgi/wiki?SingletonPattern
FoxTalk, May 1999, Jeffrey Donnici, Best Practices: Seeing Patterns: The
Singleton

Using Software Design Patterns Southwest Fox 2006

© 2006 Bill Anderson (OOP)
State Pattern
http://www.dofactory.com/Patterns/PatternState.aspx
http://c2.com/cgi/wiki?StatePattern
FoxPro Advisor, February 2002, Rick Hodder, State Pattern
Strategy Pattern
http://fox.wikis.com/wc.dll?Wiki~StrategyPattern
http://www.dofactory.com/Patterns/PatternStrategy.aspx
http://c2.com/cgi/wiki?StrategyPattern
FoxTalk, January 1997, Steven Black, Add Design Flexibility with a
Strategy Pattern
FoxTalk, February 1999, Jeffrey Donnici, Best Practices: Seeing Patterns:
The Strategy
FoxTalk, September 1999, Jeffrey Donnici, Best Practices: Seeing Patterns:
Any Questions?
FoxPro Advisor, November 2001, Rick Hodder, Strategy and Memento
Template Method
http://www.dofactory.com/Patterns/PatternTemplate.aspx
http://c2.com/cgi/wiki?TemplateMethodPattern
FoxTalk, November 1999, Jeffrey Donnici, Best Practices: Seeing Patterns:
The Template Method
FoxPro Advisor, September 2001, Rick Hodder, Reuse Code with the
Template Pattern

Credits
Many thanks are due to the people whom have previously published
and/or spoken about design patterns in the Visual FoxPro community.
These include Steven Black, Jeffrey Donnici, Yair Alan Griver, Mary
Hintemeyer, Rick Hodder and Andy Kramek.

Southwest Fox 2006 Using Software Design Patterns

(OOP) © 2006 Bill Anderson
i