DesignPatternsinActionScriptVisitor

It’s our winter holiday now, and I spend many times in playing games. In last week, I soaked myself in . I love this game, but it’s a pity for me that when I fight to the monsters, I can’t control the heroine. Because of that sometimes I need her help to shot somebody exactly not the other one. OK, I’m crazy Controlling two roles will increase the difficulty of manipulation, and it’s not a RTS game.

In RTS game, such as Warcraft, you can control many units. When your team attacks someone, the team members will use their own skills. Maybe the Dwarven Sniper will use his gun to shot, while the Mountain King uses his hammer. So, in action script, we may express these in this way.

Note: the above code is directly type in Word, so don’t try to complier it, it may contain many grammar mistakes

Now, take a look at the attack function. When you pass the team array into it, it may works well. Actually, the team member maybe more than ten, eh, I mean the type of members. So, we need to distinguish them in the iteration. This will cause many if-else. And this is the “bad smell” of our code

Here, our problem is that, in an array that may contains many objects, and the action it takes depends on the object type. Further more, the object type is fixed, and the operations of each type are also known, just as the units in Warcraft. What we want to do is organize their basic operations to form a series operation, such as a team in Warcraft to attack the creatures with their normal skills, or attack the buildings with siege skills.

Actually, our aim is to refactoring the if-else clauses. And that’s what the Visitor pattern does. The intent is as follows.

Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

–By GOF BOOK

And here is the static diagram of this pattern from the GoF book.

In the Warcraft example, the member is corresponding to the Element, eh, one for each concrete element. And the array is the ObjectStructure. The attacks is the visitor, the concrete visitor is the creature attack and building attack.

So, we can refactor the code by this pattern, let all the members implements the Element interface, and let the attacks implements the Visitor interface. And in the iteration, we can do it in this way.

Here, one accept method replace all the if-else clauses and the concrete operations. Eh, you should implement every accept method in the concrete element like this.

If you’re interested in this pattern, find more information by Google And you can take a look at the example code in the attach file. Download Full Project