Design Patterns in ActionScript-Strategy

Today, we’re going to talk about the design patterns in ActionScript. You may be familiar with those patterns if you’re familiar with OO(object oriented). But I won’t suppose you have much knowledge about it, all you need to know is just some basic OO principles, such as encapsulation, inheritance and polymorphism.

This is the first topic of design patterns, and you’ll see all the 23 design patterns in the following days. Hope you will enjoy these topics.

Let’s begin the first one now.

Demo | Download Full Project

 

Suppose you need to write some codes to mimic some birds, the first is eagle, and the other is penguin. Those two animals have two methods named migration() and fly(). You may realize you need a super class named bird, and two methods in it. Then eagle and penguin can inherit from the super class, and override the methods, ‘cause those birds have different behaviors. It seems to be perfect. You quickly write down the code.

1. class bird {
2. public   function migration () : void {
3. }
4.  
5. public   function fly () : void {
6. }
7. }
8.  
9. class   eagle extends bird {
10. public   override function migration () : void {
11. trace ( " Sorry, I don’t migrate " ) ;
12. }
13.  
14. public   override function fly () : void {
15. trace ( " flying " ) ;
16. }
17. }
18.  
19. class   penguin extends bird {
20. public   override function migration () : void {
21. trace ( " migrating… " ) ;
22. }
23.  
24. public   override function fly () : void {
25. trace ( " Sorry, I can’t fly… " ) ;
26. }
27. }

OK, it does what you want. But what would you do when you want to add a new kind of birds into your program. Suppose you need to add a duck into your program now, you can inherit from the super class bird and override the methods again. It seems that the super class doesn’t save your time, reuse your code, you need to write every methods of subclasses.

How to fix this problem? I think you need this design pattern—Strategy. And here is the definition from the GoF book. “Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.” And what’re the algorithms here? The methods, migration() and fly(). Every bird has it’s own behavior about migration and fly, it migrates or not, it flies or not.

Let me say it more clearly, we just need to implement two situations about migration and two about fly. We need to implement each situation on a single class. And we’d better to have two interfaces named flyable and migrateable, and the classes just need to implement those interfaces. The UML diagram is showing below.

Now, the super class bird needs to handle two variables of those interfaces. Using polymorphism, the super class bird can do all things we do in the subclasses. When you want to ask a eagle to fly, you can simply call the function doFlying() of class bird. You can write the code like this:

1. var littleEagle : bird = new eagle () ;
2. littleEagle . doFlying () ;

I know you may be confused now, let me show you the code of the super class bird.

1. class bird {
2. var   flyInterface : flyable ;
3. var   migrateInterface : migrateable ;
4.  
5. public   function bird ( _fly : flyable , _migrate : migrateable ){
6. flyInterface = _fly ;
7. migrateInterface = _migrate ;
8. }
9.  
10. public   function doMigration () : void {
11. migrateInterface . doMigration () ;
12. }
13.  
14. public   function doFlying () : void {
15. flyInterface . flying () ;
16. }
17. }

From the code, we can see the super class do all the things simply by call the methods of the interfaces. We don’t have to know which instance the interface points to, we only need to know it works. That’s it. Well, we’ll use the constructor to specify the instances of each interface. And here comes the code of each subclass.

1. class eagle extends bird {
2. public   function eagle (){
3. super ( new   fly () , new neverMigration ()) ;
4. }
5.  
6. }
7.  
8. class   penguin extends bird {
9.  
10. public   function penguin (){
11. super ( new   neverFly () , new migration ()) ;
12. }
13.  
14. }

If you want to add a new kind of birds, all you need to do is just write a new class, and specify the constructor. And that’s it!

If you want to change the behavior of fly or neverFly, you just need to change the code of the specific class. And all the birds’ behavior will get changed. So, the code will be more easily to maintain. In this sample the behavior is easy to change, so we need to encapsulate the behavior. The UML of all classes is showing below.

Let’s back to the definition of this pattern, “Define a family of algorithms, encapsulate each one”, we have done it. And the result is we can change the behavior or add a new bird more easily. The algorithm means the way you solve a problem, when you have many ways to solve a problem, encapsulate it, and make it interchangeable.

This sample is not good enough to show the power of this pattern, if you want to learn more about this pattern, you can look up the GoF book.