i

Session Using Software Design Patterns

Bill Andersonbilla@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.

Using Software Design Patterns Southwest Fox 2006© 2006 Bill Anderson (OOP)

Quoting from the book Design Patterns – Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and 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

Southwest Fox 2006 Using Software Design Patterns(OOP) © 2006 Bill Anderson

issues are implementation details. You’re familiar with the control, how to use it and when it’s appropriate to use such a control.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

Southwest Fox 2006 Using Software Design Patterns(OOP) © 2006 Bill Anderson

are 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 BooksCoplien, 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 Factoryhttp://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.aspxhttp://c2.com/cgi/wiki?AbstractFactoryPatternFoxTalk, 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 Patternhttp://fox.wikis.com/wc.dll?Wiki~AdapterPatternhttp://www.dofactory.com/Patterns/PatternAdapter.aspxhttp://c2.com/cgi/wiki?AdapterPatternFoxTalk, July 1999, Jeffrey Donnici, Best Practices: Seeing Patterns: The AdapterFoxTalk, September 2002, Andy Kramek and Marcia Akins, What’s in a name?

Bridge Patternhttp://fox.wikis.com/wc.dll?Wiki~BridgePatternhttp://www.stevenblack.com/PTN-Bridge.asp http://www.dofactory.com/Patterns/PatternBridge.aspxhttp://c2.com/cgi/wiki?BridgePatternFoxTalk, March 1996, Steven Black, Extend and Adapt Your Classes with BridgesFoxPro Advisor, March 1996, Yair Alan Griver, Use Patterns to Increase Reuse and FlexibilityFoxTalk, November 1998, Jeffrey Donnici, Best Practices: Seeing Patterns: The Bridge

Chain of Responsibilityhttp://fox.wikis.com/wc.dll?Wiki~ChainOfResponsibilityhttp://www.dofactory.com/Patterns/PatternChain.aspxhttp://c2.com/cgi/wiki?ChainOfResponsibilityPatternFoxTalk, April 1999, Jeffrey Donnici, Best Practices: Seeing Patterns: Chain of ResponsibilityFoxPro Advisor, December 2001, Rick Hodder, Chain of ResponsibilityFoxtalk 2.0, October 2004, Lauren Clarke and Randy Pearson, Parsing Power Tools, Part 4

Command Patternhttp://www.dofactory.com/Patterns/PatternCommand.aspxhttp://c2.com/cgi/wiki?CommandPatternFoxTalk, November 1998, Jeffrey Donnici, Best Practices: Seeing Patterns: The Command

Using Software Design Patterns Southwest Fox 2006© 2006 Bill Anderson (OOP)

Composite Patternhttp://www.dofactory.com/Patterns/PatternComposite.aspxhttp://c2.com/cgi/wiki?CompositePatternFoxTalk, November 1998, Jeffrey Donnici, Best Practices: Seeing Patterns: The CompositeFoxPro Advisor, January 2002, Rick Hodder, Composite Pattern

Decorator Patternhttp://fox.wikis.com/wc.dll?Wiki~DecoratorPatternhttp://www.stevenblack.com/PTN-Decorator.asphttp://fox.wikis.com/wc.dll?Wiki~DecoratingWithTHIS_ACCESShttp://www.dofactory.com/Patterns/PatternDecorator.aspxhttp://c2.com/cgi/wiki?DecoratorPatternFoxTalk, July 1996, Steven Black: Design Patterns: WrappersFoxPro Advisor, May 1998, Yair Alan Griver, Enhance Existing Code with the Decorator

Factory Methodhttp://www.dofactory.com/Patterns/PatternFactory.aspxhttp://c2.com/cgi/wiki?FactoryMethodPatternFoxTalk, January 2000, Jeffrey Donnici, Best Practices: Seeing Patterns: The Factory

Hook Operationhttp://fox.wikis.com/wc.dll?Wiki~HookOperationhttp://www.stevenblack.com/PTN-Hook%20Operations.asp

Iterator Patternhttp://fox.wikis.com/wc.dll?Wiki~IteratorPatternFromTexthttp://www.dofactory.com/Patterns/PatternIterator.aspxhttp://c2.com/cgi/wiki?IteratorPatternFoxTalk, June 1999, Steven Jeffrey Donnici, Best Practices: Seeing Patterns: The IteratorFoxPro Advisor, October 2001, Rick Hodder, The Iterator Pattern Makes Coding Easier

Layershttp://www.stevenblack.com/PTN-Layers.asp

Southwest Fox 2006 Using Software Design Patterns(OOP) © 2006 Bill Anderson

Mediator Patternhttp://www.stevenblack.com/PTN-Mediator.ASPhttp://fox.wikis.com/wc.dll?Wiki~MediatorPatternFromTexthttp://fox.wikis.com/wc.dll?Wiki~EasyMediatorhttp://www.dofactory.com/Patterns/PatternMediator.aspxhttp://c2.com/cgi/wiki?MediatorPatternFoxPro Advisor, April 1998, Y Alan Griver, Design Patterns, Observers and MediatorsFoxTalk, December 1998, Jeffrey Donnici, Best Practices: Seeing Patterns: The Mediator

Memento Patternhttp://www.dofactory.com/Patterns/PatternMemento.aspxhttp://c2.com/cgi/wiki?MementoPatternFoxTalk, May 1998, Barbara Peisch and Paul Maskens, Kit Box: Saving and Restoring ObjectsFoxPro Advisor, November 2001, Rick Hodder, Strategy and Memento

Observer Patternhttp://fox.wikis.com/wc.dll?Wiki~ObserverPatternhttp://fox.wikis.com/wc.dll?Wiki~ObserverPatternExamplehttp://fox.wikis.com/wc.dll?Wiki~ObserverPatternFromTexthttp://www.dofactory.com/Patterns/PatternObserver.aspxhttp://c2.com/cgi/wiki?ObserverPatternFoxTalk, April 1996, Steven Black, Design Patterns: Abstract one-to-many Relationships with ObserverFoxPro Advisor, April 1998, Y Alan Griver, Design Patterns, Observers and MediatorsFoxTalk, January 1999, Jeffrey Donnici, Best Practices: Seeing Patterns: The Observer

Singleton Patternhttp://www.dofactory.com/Patterns/PatternSingleton.aspxhttp://c2.com/cgi/wiki?SingletonPatternFoxTalk, May 1999, Jeffrey Donnici, Best Practices: Seeing Patterns: The Singleton

Using Software Design Patterns Southwest Fox 2006© 2006 Bill Anderson (OOP)

State Patternhttp://www.dofactory.com/Patterns/PatternState.aspxhttp://c2.com/cgi/wiki?StatePatternFoxPro Advisor, February 2002, Rick Hodder, State Pattern

Strategy Patternhttp://fox.wikis.com/wc.dll?Wiki~StrategyPatternhttp://www.dofactory.com/Patterns/PatternStrategy.aspxhttp://c2.com/cgi/wiki?StrategyPatternFoxTalk, January 1997, Steven Black, Add Design Flexibility with a Strategy PatternFoxTalk, February 1999, Jeffrey Donnici, Best Practices: Seeing Patterns: The StrategyFoxTalk, September 1999, Jeffrey Donnici, Best Practices: Seeing Patterns: Any Questions?FoxPro Advisor, November 2001, Rick Hodder, Strategy and Memento

Template Methodhttp://www.dofactory.com/Patterns/PatternTemplate.aspxhttp://c2.com/cgi/wiki?TemplateMethodPatternFoxTalk, November 1999, Jeffrey Donnici, Best Practices: Seeing Patterns: The Template MethodFoxPro Advisor, September 2001, Rick Hodder, Reuse Code with the Template Pattern

CreditsMany 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

Using Software Design Patterns Southwest Fox 2006© 2006 Bill Anderson (OOP)