One of the simplest and most commonly used patterns is definitely strategy pattern. We cannot pass a boring definition, so here you go:

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy algorithm vary independently from clients that use it.

You will find out that all strategy pattern really enforces is you to plan your code for change. In this article, I would like to present use of Strategy pattern in LotusScript.

More details can be found at Wikipedia or Head First Design Patterns book.

For the presentation example I have chosen product handling in a shopping cart. Why? Mainly because e-commerce is something most of us, Lotus developers have to deal with at some point in our careers.

So, imagine following scenario. You got a job at a software company that produces and sales business software. They used to do it via a simple product (e.g. events, electronic downloads, hard copies etc.) list on the web (using notes database) and a telephone number next to it. The company feels they should focus more on their customers and make them a friendly web environment for browsing and shopping. Thus, eliminating that phone call that no one likes to make. Now, you are the person to do it. And of course, they want it yesterday.

First, you need to sit down and think. They have at least three types of products, each displaying differently due to its delivery behavior. Also, a user can have a discount for a certain product. Here, the strategy pattern jumps in to help.

You need to create a behavioral interfaces. Or in this case two (first for delivery, second for discount). Unfortunately, LotusScript doesn’t do interfaces, so you will have to replace that with an abstract class.
So, two abstract classes, with single methods in it as shown below.

Next, you need to create all behavioral classes that you need. For delivery, you have three behaviors: on-site event, electronic download, or mailing the hard copy. For discount, there are only two behaviors thus far: discount and no discount. Pseudo-code is shown below.

Now it is time you start thinking of products. Different product types normally do not share all properties. Thus, it is wise to create an abstract class for products and then several classes that inherit from that abstract class. In this example we obviously have at least two different product types. One are events, the other one is software. Pseudo-code is shown below.


That is all there is to the Strategy Pattern. Please refer to above mentioned links for further guidance. If you have any further questions, comment.