Introduction to Design Patterns

Introduction to Design Patterns

It’s been a while!

It’s been a while since I have had the time to update my blog and there are several reasons for that, not least of which has been the good one that I have been extremely busy, professionally, working on a number of very interesting projects. Most recently, Marcia and I traveled to Frankfurt to speak at the 13^th European DevCon where we joined Craig Bernston, Doug Henning, Lisa Slater-Nicholls and Rick Schummer.

This was, as always, a G R E A T conference and it remains an abiding mystery to all of us who have ever attended it why so few people from the US have ever been to it. Flights are (relatively) cheap and plentiful, and the opportunity to attend a genuinely good VFP conference combined with a little European rest and recreation just seems like a good idea. You can find details of what you missed in various places on line, including the Universal Thread coverage and the blogs of fellow presenters Craig, Doug and Rick.

I plan to start another little series of blog articles, right now, on the subject of design patterns. This is something that has long been of interest to me (see “The Revolutionary Guide to Visual FoxPro OOP”, Wrox Press, 1996 written by Will Phelps, Bob Groomes and myself, for some early examples of pattern-based design with VFP) and, judging by the comments and discussions that I hear at conferences, I am not alone in my interest. The commonest question I hear is ‘How do I use Design Patterns in VFP?’ and that is what I will try to address in this little series – at least for some of the most common patterns.

Why Bother with Design Patterns?

Design patterns offer a standard language for recognizing, defining and describing solutions to software problems. A knowledge of design patterns makes it easier to understand existing systems and to describe requirements for complex new systems.

I remember, several years ago, sitting with Paul Maskens in the lobby of the Lindner Conference Hotel in Frankfurt while he explained an idea for a Kitbox column to me. He was describing a solution to a problem that he had developed and, suddenly, after about 20 minutes, I realized that what he was talking about was a ‘strategy pattern’. Had he started out by saying that he had implemented a strategy pattern I would have known immediately what the general issues were, and the approach that he had adopted to solve them. It would have saved a lot of time and effort and allowed us both to focus on the details of the implementation.

However it is important to recognize that Design Patterns are not, themselves, the actual solutions to specific problems. They are simply ways of identifying problems and describing generic solutions that have been proven to work. The actual implementation of a design pattern is still the job of the application developer.

What is a Design Pattern?

Before I dive into specific examples of how to implement specific design patterns in Visual FoxPro I should start by defining what is meant by a ‘Design Pattern’. Various definitions have been proposed and perhaps the most widely quoted is that from the seminal work “Design Patterns, Elements of Reusable Object-Oriented Software” by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (usually referred to as ‘the gang of four” or more simply as “GoF”). They offer, in the first chapter of their book,  “What is a Design Pattern”, the following definition:

A design pattern names, abstracts, and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design. The design pattern identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities.

This is a good definition because it encapsulates the four key elements of any design pattern.

·         It has a name. This is vital because it allows developers to overcome one of the fundamental problems of software design - how to communicate what you are doing to others. The example of Paul and I discussing an idea for an article, that I gave above, illustrates this point perfectly.

·         It abstracts the problem. This is referred to by “GoF” as the ‘intent’. It tells us both the nature of the problem and the solution described by a pattern. Consider the common problem of preventing users from creating multiple instances of an application. Typically users try to start new instances of the application because, having minimized the main screen, they forget that it is there and click the desktop icon instead of maximizing the existing instance. We can see immediately that the Singleton pattern is likely to be relevant because its intent is given as being to “Ensure a class only has one instance, and provide a global point of access to it”.

·         It defines a design structure. It is important to realize that design patterns do not provide solutions to problems. They describe structures that allow you to solve a problem in a manner that is more likely to be reusable than if you simply wrote code to solve the problem in the context in which it arises. We have all been through the experience of realizing we have already solved a particular problem elsewhere in our code, but that we cannot re-use it because we did not isolate the solution from the situation. The purpose of a design pattern is to help you recognize situations like this and avoid them.

·         It identifies the distribution of responsibilities. This is, of course, the key to all design issues and is not limited to design patterns. After all, once we know what a class (or object) has to do, writing the code to make it do it is relatively easy. The benefit of a design pattern is that once we recognize a problem and match it to a pattern, the pattern tells us how we should allocate the responsibilities and therefore helps us create the ‘best’ solution quickly.

It is not my intention, to offer an exhaustive review of every known design pattern (there are whole books devoted to that). But in this little series I plan to cover the most commonly encountered patterns and show how Visual FoxPro can be used to implement pattern-based solutions. Each article will be self-contained and will cover one pattern, but I will try, wherever possible, to keep to a common thread.

Hopefully you will find the information useful, and if you do have any comments please feel free to post them.

Published Saturday, December 02, 2006 12:30 PM by andykr