When looking at the key features of the Strategy pattern, you’ll benefit from comparing them with the key features of the State pattern in the previous chapter (Chapter 10). The comparison will not only help you understand the difference between the State and Strategy patterns, it’ll also help you better understand each pattern in its own right.

The following key features are used in concert to create the Strategy design pattern, but you will find the same elements when looking at good practices for just about any object-oriented programming:

Before going back to Chapter 10 and looking at the list of features in the State pattern, take a look at the next section, “The Strategy Model.” Then make the comparison. Right off the bat you’ll see that the key features of the State and Strategy differ, but by comparing the models as well, you’ll see the differences more clearly.

Because the features of the Strategy pattern are so fundamental to good OOP, we’re going to save a more detailed discussion of them for the section, “Key OOP Concepts used with the Strategy Pattern.” As you’ll see, all the features are discussed as applicable to the more general principles of programming with OO languages such as ActionScript 3.0.

When you look at the class diagram for the Strategy design pattern, you may be struck by a sense of déjà vu. In Figure 11-3 in Chapter 10, the labels look different, but the State design looks very similar. Fear not. They’re very different in intent and implementation. So in looking at Figure 11-1, keep the Strategy design pattern key features in mind.

Figure 11-1. Strategy design pattern class diagram

Looking at the Context class in the Strategy class diagram, you can see that the Strategy interface is an aggregate of the Context class. Because of this aggregation, we can say that the Context class (aggregator) owns the Strategy interface (aggregate), just as in the State design pattern. (See Figure 10-3 in Chapter 10.) As you will see in the examples, the Context class aggregates the Strategy operations. Because aggregation is so fundamental to many of the design patterns and an integral part of OOP, look for its actual use in the examples. The Strategy design pattern is one of the best sources of clear examples showing aggregation at work.

In Chapter 10, you saw that with the State design pattern, the states varied in the video player, and so the State object encapsulated the state-dependent behavior, such as playing and stopping the video. With the Strategy pattern, the Strategy object encapsulates algorithms. What both these design patterns have in common is that the elements that change are encapsulated. (As a hint of what is encapsulated, look at the name of the class. In both the State and Strategy classes, the encapsulating object is the name of the class—check the class diagrams.)

More important is why GoF suggests encapsulating those concepts that vary. Essentially, if you encapsulate those parts that vary, then, when you change the application, you’ll have fewer surprises. Encapsulated concepts allow the objects in object-oriented programming to act like objects. Rather than being sticky-glued to and dependent on other elements in a single program, encapsulated objects can act in concert with any new element added to the application, because they can vary independent of other objects.

To better see what it means to encapsulate what varies, consider a script from an example in this chapter with and without encapsulation. This involves clowns and what they do in clown venues.

class Clown {
    function juggle() {
    //juggle code
    }
    function balloonAnimals() {
    //balloon animal code
    }
}

class Bojo extends Clown {
    //Bojo unique
}

class Koka extends Clown {
    //Koka unique
}

interface ClownTricks {
    function someTrick(): void;
}
class Juggle implements ClownTricks {
    function someTrick(): void {
     //Juggling algorithm
    }
class BalloonAnimals implements ClownTricks {
    function someTrick(): void {
     //Making balloon animal algorithm
    }

The Strategy design pattern is a perfect example of delegation. In delegation, two objects are involved in handling a single request. One of the objects receives the request and then delegates operations to a delegate. This is exactly what transpires between the context classes and the strategy classes. The context classes are made up of class and its subclasses. The context classes delegate actions to the strategy classes, made up of strategy interfaces and implementations of those interfaces. So the context classes delegate to the strategy classes.

The delegation process begins in the main context class. It includes reference variables to the strategy interfaces. Methods in the context class do the actual delegation. The concrete context classes inherit the instance variables from the context class, and use those variables to specify which behaviors they want from the concrete strategies. Figure 11-2 shows a visual depiction of delegation.

Figure 11-2. Delegation

If an instance of a class, which has a reference to a delegate that is called, is called, the delegate invokes the called method containing the encapsulated algorithm. So instead of inheriting the operation, the object can be said to have a method that handles a call.

The Context class shown in Example 11-1 is an aggregator —it owns the Strategy object. So in every Context class where Strategy patterns are found, you will find a reference to the strategy class—in this example a variable taking the lowercase name of the Strategy interface. (Example 11-1 to Example 11-5 make up the first application.)

package
{
    class Context
    {
        protected var strategy:Strategy;

        public function doStrategy():void
        {
            strategy.think();
        }
    }
}

The Context class is pretty simple. One reason is that all the methods it needs are delegates implemented from the Strategy interface. Let’s now look at such an interface.

In a Strategy design pattern, you’re likely to see more than one interface, depending on the different types of methods required. Example 11-2 shows a single method in the interface.

package
{
    interface Strategy
    {
        function think():void;
    }
}

This represents the first step in encapsulating a behavior. The subsequent concrete Strategy implementations add detail.

Next, in Example 11-3, a concrete strategy adds a method, think(), which does something. In this case, it just sends out a trace message.

package
{
    class ConcreteStrategy implements Strategy
    {
        public function think():void
        {
            trace("Great thoughts now...");
        }
    }
}

In a concrete context class as in Example 11-4, you can see that the work is delegated to a concrete strategy class.

package
{
    class ConcreteContext extends Context
    {
        public function ConcreteContext()
        {
            strategy = new ConcreteStrategy();
        }
    }
}

Finally, to test the Strategy design pattern, Example 11-5’s script creates an instance of the concrete context, but types the instance as a Context data type—an example of programming to the interface and not the implementation.

package
{
    import flash.display.Sprite;

    public class TestStrategy extends Sprite
    {
        public function TestStrategy()
        {
            var thinker:Context= new ConcreteContext();
            thinker.doStrategy();
        }
    }
}

Now that you have an abstract Strategy design pattern where you can see the arrangement of the different parts, an illustration where you can see all of the connections, delegation and interactions in a single view will give you an overview of the process. Figure 11-3 shows the connections between the different parts, all in one view.

Figure 11-3. Delegation connections

In Figure 11-3, note how the call,

thinker.doStrategy();

is delegated. The thinker instance in the TestStrategy class is typed as a Context type and instantiated as a ConcreteContext object. The doStrategy() method is created in the Context class, and so that would be the first place to look, as the arrow from doStrategy() in the TestStrategy class to the doStrategy() in the Context class shows.

However, in the Context class the doStrategy() method has delegated the details to the think() method, so we need to look elsewhere. In the ConcreteStrategy class, you can see the details of the think() method. Because the ConcreteContext strategy is instantiated in the thinker instance, it actually did the work, but since ConcreteContext is a subclass of Context, the delegation is structured in the Context class.

Finally, we can trace the delegation framework back to the Strategy interface. Because the origin of the think() method is in the Strategy class, we can see how it is a delegate of the Context class.

The first step is to create a context class and concrete contexts that will use the different tricks and skits. Example 11-6 is the main context class establishing the references to the strategy methods. The trick and skit operations are delegated to the strategy classes. Then Example 11-7 and Example 11-8 create two concrete clowns. Each is assigned a different trick and skit that are delegated to concrete strategy instances. To get started, open three ActionScript files and enter the code in Example 11-6 to Example 11-8, saving each with the caption name provided. (Example 11-6 through Example 11-16 make up the entire application.)

package
{

    class Clown
    {
        protected var tricks:Tricks;
        protected var skits:Skits;

        public function doTrick():void
        {
            tricks.trick();
        }

        public function doSkit():void
        {
            skits.skit();
        }
    }
}

package
{
    class Koka extends Clown
    {
        public function Koka()
        {
            tricks = new Disappear();
            skits = new Chase();
        }
    }
}

package
{
    class Bojo extends Clown
    {
        public function Bojo()
        {
            tricks = new BaloonAnimals();
            skits = new FallDown();
        }
    }
}

Notice that each clown can perform only a single trick and a single skit. We’ll have to reconsider how to set up our strategies, or see if we can find a way to dynamically add features later. For now, though, the clowns can choose only a single trick or skit.

All the algorithms for doing tricks are encapsulated in the concrete strategy subclasses. The Tricks interface (Example 11-9) provides the abstract method, and the subclasses add detail to the operations. A total of three trick algorithms (Example 11-10, Example 11-11, and Example 11-12) are implemented.

package
{
    interface Tricks
    {
        function trick():void;
    }
}

package
{
    //Make Balloon Animals
    public class BalloonAnimals implements Tricks
    {
        public function trick():void
        {
            trace("See! It's a doggy! No, it's not an elephant!!
")
        }
    }
}

package
{
    //Make Something Disappear
    public class Disappear implements Tricks
    {
        public function trick():void
        {
            trace("Now you see it! Presto! It's gone!
")
        }
    }
}

package
{
    //Juggle Balls
    public class Juggle implements Tricks
    {

        public function trick():void
        {
            trace("Look at me juggle! Whoops!
")
        }
    }
}

By using a general concept like “tricks,” we’re limiting the range of what the clowns can do. The way the Strategy pattern’s set up, each clown can have only a single trick. We could implement an “All Tricks” class, but that’s too broad at the opposite extreme in that it would require a clown to do everything, even if he could only do two of the tricks.

The Skits interface (Example 11-13) and its implemented classes (Example 11-14 and Example 11-15) are set up exactly the same as the Tricks class and its implementations. It also has the same limitations.

package
{
    //Skits Interface
    interface Skits
    {
        function skit():void;
    }
}

package
{
    //Falls down a ladder
    public class FallDown implements Skits
    {
        public function skit():void
        {
            trace("I'm climbing up this ladder!")
            trace("Where's my banana peel?")
            trace("Whoaaaa! I'm falling!!")
            trace("Thanks for finding my banana peel!
")
        }
    }
}

package
{
    //Clowns chase each other
    public class Chase implements Skits
    {
        public function skit():void
        {
            trace("Here I come! I'm going to get you!")
            trace("Nah! Nah! Can't catch me!
")
        }
    }
}

Even though we’ve discussed some possible shortcomings in this design, it still shows how the strategies are built in the implementations of the Tricks and Skits classes. The final step is to see how to launch the program.

For this example, the ClownCollege class (Example 11-16) instantiates two different clowns. Both clowns are typed as Clown types following the dictum of programming to the interface instead of the implementations; however, each instantiates through a Clown subclass. Each is given a trick and skit, and it’s ready to run. Save Example 11-16 using the caption name as the filename.

package
{
    import flash.display.Sprite;

    public class ClownCollege extends Sprite
    {
        public function ClownCollege()
        {
            var joker:Clown=new Koka();
            joker.doTrick();
            joker.doSkit();

            var gagGrrrl:Clown=new Bojo();
            gagGrrrl.doTrick();
            gagGrrrl.doSkit();
        }
    }
}

Once you’re finished saving Example 11-6 Example 11-16, open a new Flash document and save it as ClownCollege.fla. In the Document class window, type in ClownCollege and test the application. You should see the following in the Output window:

* =>Koka<= *
Now you see it! Presto! It's gone!

Here I come! I'm going to get you!
Nah! Nah! Can't catch me!

* =>Bojo<= *
See! It's a doggy! No, it's not that!!

I'm climbing up this ladder!
Where's my banana peel?
Whoaaaa! I'm falling!!
Thanks for finding my banana peel!

The output represents the algorithms set up in the strategy classes. All are delegated from the Clown context class and implemented in the concrete clown classes.

As noted in the initial clown application using the Strategy design pattern, the structure allowed very little flexibility and no way to dynamically change a concrete context to accept another strategy. So what happens if we add another clown who can do more than one trick but not all the tricks?

Fortunately, we have a simple solution. By adding setters to the context class, Clown, it will be possible to dynamically add strategies to the concrete context classes—the clowns. Example 11-17 revises the original Clown class by adding the setters (shown in bold).

package
{
    class Clown
    {
        protected var tricks:Tricks;
        protected var skits:Skits;

        public function doTrick():void
        {
            tricks.trick();
        }

        public function doSkit():void
        {
            skits.skit();
        }

        public function setTrick(addTrick:Tricks):void
        {
            tricks=addTrick;
        }

        public function setSkit(addSkit:Tricks):void
        {
            tricks=addSkit;
        }
    }
}

package
{
    class Bubbles extends Clown
    {
        trace("* =>Bubbles<= *");
        public function Bubbles()
        {
            tricks=new Juggle();
            skits = new FallDown();
        }
    }
}

package
{
    class BubblePants implements Tricks
    {
        public function trick():void
        {
            trace("Woo woo woo! Bubbles are coming out of my pants!
");
        }
    }
}

package
{
    import flash.display.Sprite;

    public class ClownCollege extends Sprite
    {
        public function ClownCollege()
        {
            var joker:Clown=new Koka();
            joker.doTrick();
            joker.doSkit();

            var gagGrrrl:Clown=new Bojo();
            gagGrrrl.doTrick();
            gagGrrrl.doSkit();

            var gurgle:Clown=new Bubbles();
            gurgle.doSkit();
            gurgle.doTrick();
            gurgle.setTrick(new BubblePants());
            gurgle.doTrick();
        }
    }
}

* =>Koka<= *
Now you see it! Presto! It's gone!

Here I come! I'm going to get you!
Nah! Nah! Can't catch me!

* =>Bojo<= *
See! It's a doggy! No, it's not that!!

I'm climbing up this ladder!
Where's my banana peel?
Whoaaaa! I'm falling!!
Thanks for finding my banana peel!

* =>Bubbles<= *
I'm climbing up this ladder!
Where's my banana peel?
Whoaaaa! I'm falling!!
Thanks for finding my banana peel!

Look at me juggle! Whoops!

Woo woo woo! Bubbles are coming out of my pants!

Before going on to the next example, we need to consider how the strategy subclasses were organized for the task at hand. Keep in mind that no matter how sophisticated or cool your application is, good planning will make it better.

The more components in your system, the more granularity your application is said to have. Granularity affords more flexibility, and that’s a good thing. However, greater granularity also leads to a greater number of classes, often adding housekeeping headaches.

To optimize your application, especially one using the Strategy design pattern where you can have a large number of both concrete contexts and strategies, you need to plan. Taking a closer look at the clown example, we can see where our planning was incomplete.

Starting with the trick strategies, the structure allows for only a single trick per clown. So, we might want to reorganize the strategies from what we have to something like that shown in Table 11-1:

Now, instead of a single trick interface, it has three. Additionally, a general algorithm covering any tricks in the category is covered as well (any object, any shapes and any magic). To cover contingencies, the context class retains its ability to dynamically add a strategy to an instance of a concrete context object. The skit strategies can be reorganized as well, and new strategies can be added as the application grows and changes.

You can think of the context classes as the clients for the strategies. They use the different strategies. Often, you will hear that a client has-a behavior. Whenever a client class delegates to a delegate class, such as the strategy classes in Figure 11-5, it has-a behavior generated by the strategy class. In this application, the context classes represent the client classes for the strategy classes.

Like all context classes, the StringChecker class in Example 11-21 sets a reference to the two strategy interfaces, StringWork and SortWork. In addition, it has functions, workStrings() and workSorts() that constitute the methods used to delegate work to the strategies.

package
{
    //Context class
    class StringChecker
    {
        protected var stringWork:StringWork;
        protected var sortWork:SortWork;
        public function StringChecker():void
        {
        }

        public function workStrings(s:String):String
        {
            return stringWork.stringer(s);
        }
        public function workSorts(a:Array):Array
        {
            return sortWork.sorter(a);
        }
        public function setString(sw:StringWork):void
        {
            stringWork=sw;
        }
        public function setSort(sow:SortWork):void
        {
            sortWork=sow;
        }
    }
}

In addition to having reference properties and methods, the context class includes setter operations, setString() and setSort(), to dynamically set strategies to instances of the context classes.

Next, in Example 11-22 and Example 11-23, two concrete context classes extend the primary context class. Note that they inherit the references to the strategies, stringWork() and sortWork(). These references are then used to specify exactly which of the concrete strategies each will be using.

package
{
    //Concrete Context
    class Checker extends StringChecker
    {
        public function Checker()
        {
            stringWork = new EmailCheck();
            sortWork = new SimpleSort();
        }
    }
}

package
{
    //Concrete Context
    class Passwork extends StringChecker
    {
        public function Passwork()
        {
            stringWork = new PasswordVerify();
            sortWork = new SortAll();
        }
    }
}

Keep in mind that both of these classes inherit the methods of the main context class, StringChecker, and when you test instances of these classes, you will be using the workStrings() and workSorts() methods.

The classes associated with the strategies are quite simple by comparison to the client classes in the Strategy design pattern. The interfaces specify the methods, and then each of the concrete strategy classes implements them, supplying the details in the form of algorithms. However, in this example (Example 11-24 and Example 11-25), both methods in the interfaces require parameters and expect returns.

package
{
    //Strategy
    interface StringWork
    {
        function stringer(s:String):String;
    }
}

package
{
    //Strategy
    interface SortWork
    {
        function sorter(a:Array):Array;
    }
}

Even with the added parameter and the return datatype, the interfaces are very simple. They get more interesting in their implementation.

package
{
    //Concrete Strategy
    class EmailCheck implements StringWork
    {
        public function stringer(s:String):String
        {
            var atPlace:int=s.indexOf("@");
            if (atPlace != -1 && atPlace !=0 && atPlace != (s.length-1))
            {
                return "Email address verified";
            } else
            {
                return "Email does not verify.
Missing or
                    misplaced @ sign";
            }
        }
    }
}

package
{
    //Concrete Strategy
    class PasswordVerify implements StringWork
    {
        public function stringer(s:String):String
        {
            var pwv:String=s;
            pwv=pwv.toLocaleLowerCase();
            if (pwv == "sandlight")
            {
                return "Welcome to Sandlight";
            } else
            {
                return "Your password is incorrect.
                     Please enter again.";
            }
        }
    }
}

package
{
    //Concrete Strategy
    class SimpleSort implements SortWork
    {
        public function sorter(a:Array):Array
        {
            a.sort();
            return a;


        }
    }
}

package
{
    //Concrete Strategy
    class SortAll implements SortWork
    {
        public function sorter(a:Array):Array
        {
            a.sort(Array.CASEINSENSITIVE);
            return a;


        }
    }
}

package
{
    //Concrete Strategy
    class SortBack implements SortWork
    {
        public function sorter(a:Array):Array
        {
            a.sort(Array.CASEINSENSITIVE | Array.DESCENDING);
            return a;

        }
    }
}

Two support classes help keep the main test application clear, and make good use of the whole idea of a class structural arrangement. The ShowText class (Example 11-31) organizes a dynamic text field, and TextShow (Example 11-32) provides the format.

package
{
    import flash.text.TextField;
    import flash.text.TextFieldType;

    class ShowText extends TextField
    {
        public function ShowText():void
        {
            this.type=TextFieldType.DYNAMIC;
            this.multiline=true;
            this.wordWrap=true;
            this.border=true;
            this.borderColor=0xcccccc;
        }
    }
}

package
{
    import flash.text.TextFormat;

    class TextShow extends TextFormat
    {
        function TextShow():void
        {
            this.font="Verdana";
            this.color=0xcc0000;
            this.size=11;
            this.leading=3;
            this.leftMargin=11;
            this.rightMargin=6;
        }
    }
}

Feel free to change any of the support classes’ features to meet your own tastes.

The test of the applied Strategy design pattern uses two objects (Example 11-33). The first object instantiates the concrete context class, Checker, and the second uses Passwork.

package
{
    import flash.display.Sprite;

    public class TestStringStrategy extends Sprite
    {
        private var showText:ShowText;
        private var showText2:ShowText;
        private var textShow:TextShow;

        public function TestStringStrategy():void
        {
            doText();

            //Stringer -- Uses Checker concrete context
            var stringer:StringChecker= new Checker();
            showText.text="Stringer

"+stringer.workStrings
                ("[email protected]");
            var friends:Array=new Array("John","Carl","aYo","Delia");
            showText.appendText("
"+stringer.workSorts(friends));
            stringer.setString(new PasswordVerify());
            showText.appendText("
"+stringer.workStrings("Sandlight"));

            //Passer -- Uses Passwork concrete context
            var passer:StringChecker= new Passwork();
            showText2.text="Passer

"+passer.workStrings("Rumple");
            showText2.appendText("
"+passer.workSorts(friends));
            passer.setSort(new SortBack());
            showText2.appendText("
"+passer.workSorts(friends));
            passer.setString(new EmailCheck);
            showText2.appendText
                ("
"+passer.workStrings("@passGuy.com"));
        }
        private function doText():void
        {
            showText=new ShowText();
            showText2=new ShowText();
            textShow=new TextShow();
            showText.defaultTextFormat = textShow;
            showText2.defaultTextFormat = textShow;
            addChild(showText),addChild(showText2);
            showText.x=50, showText2.x=270;
            showText.y=100, showText2.y=100;
            showText.width=200,showText2.width=200;
            showText.height=150,showText2.height=150;
        }
    }
}

Keep in mind that the call to the concrete class methods, workStrings and workSorts, are calls that are delegated to the strategy classes. After opening a new Flash document file and placing TextStringStrate in the Document class window, test the application. Figure 11-5 shows what you can expect to see.

Figure 11-5. Output from TestStringStrategy

Also, note that after the dynamic changes were reset using setString() and setSort(), the output changes. Even though adding the setter is optional for a true Strategy design pattern, setters add a whole other level of flexibility and should not be overlooked.