Introduction to Design Patterns

This section relays heavily on your familiarity with basic code design concepts and approach. Make sure you read the introduction to code design before proceeding.

Parts of the following introduction are rewrites (more accurately downgrades) of the preface to the groundbreaking book Design Patterns: Elements of Reusable Object-Oriented Software, written by the “Gang of four”. If you’ll find the concept of Design Patterns useful, I strongly recommend you read the original book, and do it several times.

Background

Design Patterns are part of a design concept that arose from the field of architecture and city-planning. It was first specifically mentioned by Christopher Alexander the book “A Pattern Language”, where it applied for buildings, parks and the implementation of city-life principles in architectural design.

Alexander states this about Design Patterns: “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”

Even though Alexander was talking about architectural structures, the spirit of things and point of view applies to code structures just as well. We may talk of objects and functions instead of doors and parks, but in a more general sense, we too struggle with implementing the same core solutions to a repeating set of problems. In order to better understand that last sentence, let’s look at design patterns from a QTP programmer point of view.

What are design patterns?

First of all, a disclaimer. As with many other code design principles and terms, Design Patterns are traditionally “meant for” object-oriented languages. We shall make some adjustments and downgrades in order to bring the concept into the world of QTP and VBScript. So when we’ll refer to a specific pattern, or even the entire concept, we’ll probably mean something a little different than what you’ll find in the books or on the web. With that, let us continue.

So, exactly what are Design Patterns in the world of software and code? The definition is tricky, but for our purposes we’ll focus on a much narrower version of it (which would probably make the Gang of Four jump from a roof). Anyone who has ever written code finds out that he’s reusing some of the code over and over again. What’s usually done in such cases is wrapping the reusable code in a function, and calling it instead of duplicating the code.

Design Patterns extend the same basic principle. Anyone who’s written code on several systems (or, being a QTP programmer – for several systems) finds out that even if the actual code he’s writing is different than before, he’s resolving the same abstract problems over and over again. In these cases, even though the solution is Implemented in a different way each time (e.g. How do we deal with the specific error messages in the system), the solution Design is usually the same (e.g. we have a central analyzer function which receives the message and decides on the needed course of action).

So, oversimplifying, we can say that Design Patterns are these recurring problems, the context in which they exist and their conceptual solutions. Experienced programmers are able to use these solution patterns without regressing into thinking in “atomic” terms. For instance, imagine a writer who’s about to write his next novel. He doesn’t build the story one line at a time, but rather through general patterns such as “the tragic hero” or “the fallen price”.

Similarly, Experienced QTP programmers don’t plan their script by thinking of For, Next and If, one command at a time. They simply plan to write a serial search with an exit condition, as a complete and unbreakable pattern. Design Patterns make us concentrate on the big picture rather then the atomic commands, thus enabling us to easily understand big chunks of code, and bring order into chaos.

Nothing new but a point of view

As you might have understood, at some level, you’re already using design patterns. If you just shift your point of view you could see that even a simple checkpoint is just one implementation of a wide and rich design pattern (more on that later). The benefit in the new point of view can be evident by referring to “a script branching decision point” instead of a “text checkpoint”. The latter is a strict technological detail, while the former explains the meaning of the action, is opened to multiple implementations, and just makes more sense. Seeing things this way can also enable you to save tons of time by copying your solutions from project to project, even though there might not be a single common code-line between them.

At the end of the day, Design Patterns will help you program better, faster and cleaner. ’nuff said.

A modest example

An example might help us to better nail the concept. While the following structure may not count as a traditional Design Pattern, we may think of it as such, at least for our narrow QTP context. This code structure was discussed in a previous article, and today we’ll use it to illustrate the meaning of Design Patterns.

In almost any test we’re faced with the problem of script branching – i.e. deciding on how to continue the script according to a set of conditions. The most common branch involves activating a trigger (e.g. pressing a Submit button), and checking an expected result (e.g. a confirmation window opens). The next steps of the script are determined according to the actual result (e.g. pass if the window appears in under 30 sec., fail and exit the script if it doesn’t). Unlike “regular” programs, we don’t have all the data needed to make a decision in our script, and we have to go “to the real world” and check certain conditions there (e.g. does the window object exist) – usually while involving some kind of time measuring.

The most common implementation of a time-limit branching structure is the native QTP checkpoint. I’ve already discussed why this implementation isn’t quite adequate from a technical point of view, and have offered the following pattern as an alternative (for a detailed review of the discussion and this code, see the original article):

iTimer = Timer ‘Get the current time

DoTriggerEvent 'E.g. : click a button, submit a form, close a window, etc.

Do

    'Inner code to deal with anomalies.

Loop until (Timer-iTimer>30) Or (ExitCondition=True) ‘More exit conditions if needed

'Here we wait 30 seconds before exiting the loop

If Timer-iTimer>30 Then

    'Code to deal with TimeOut

Else

    'More code to deal with different exit conditions

End if

This code structure embodies much of the spirit and concepts of Design Patterns. It offers a very general solution, which can have a thousand different implementations according to the specific problem at hand. However, for all their differences between them, all these separate implementations track the same logical frame of mind and the same principles as the above code skeleton.

Once you’ve understood how the pattern works, you can instantly solve any problem within its domain. Of course you’ll have to sort out the specifics, but it’s safe to say the any relevant problem will be reduced to a task. This is one of the strongest benefits of fitting the world into Design Patterns – it turns out that much of the unknown world is just different implementations of the already known and scripted world.

Even switching the terminology is useful – instead of getting dragged into details and tiresome explanations, you can just tell your co-worker that you’ve implemented a time-limit branching pattern, and be done with it. If he’d ever need to, he can learn the specific details of that specific implementation, but even without the details, the code will immediately become readable, and even skimmable. And you know what? After a while you won’t even need to tell your co-worker – the pattern has such a strong signature (once you’re familiar with it), it immediately stands out as a complete logical unit, regardless of the exact implementation.

Where do we go from here?

This article was simply meant to present the general concept of Design Patterns and explain it in the least technical sense possible. Since it’s such a tricky and elusive subject, I’ve used lots of examples and analogies, and I hope that they’ve served their purpose. In future articles we’ll approach Design Patterns from a more technical point of view, and see how they can fit into our QTP scripts and techniques.

It’s quite alright if the concept still eludes you. Quoting the Gang of Four themselves, in the preface to their book: “Don’t worry if you don’t understand this book completely on the first reading. We didn’t understand it all on the first writing!”. Hopefully, once we’ll introduce some more patterns and implementations, both the concept and the details of Design Patterns will be made clear.

While you wait for future articles in this section, I strongly recommend you skim through some of the background Design Patterns material on the web. Here’re some recommended resources:

Design Patterns @ Wikipedia.

Design Patterns @ go4Expert.

Old yet “Really good books” on Design Patterns.