Design Patterns in ActionScript-Visitor

最新推荐文章于 2016-10-27 15:40:59 发布

iteye_9367

最新推荐文章于 2016-10-27 15:40:59 发布

阅读量104

点赞数

分类专栏：设计模式文章标签： ActionScript Google

本文链接：https://blog.csdn.net/iteye_9367/article/details/81685537

版权

设计模式专栏收录该内容

28 篇文章 0 订阅

订阅专栏

It’s our winter holiday now, and I spend many times in playing games. In last week, I soaked myself in <Prince of Persia: the sands of time>. 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.

Var team : Array = new Array () ;
team . push ( new DwarvenSniper ()) ;
team . push ( new MountainKing ()) ;
team . push ( new Priest ()) ;
function attack ( team : Array ) : void
{
for ( var i : int = 0 ; i < team . length ; i ++ )
{
If ( team [ i ] instanceof DwarvenSniper )
DwarvenSniper ( Team [ i ]) . gunShot () ;
Else if ( team [ i ] instanceof MountainKing )
MountainKing ( Team [ i ]) . hammerShot () ;
Else if ( team [ i ] instanceof Priest )
Priest ( Team [ i ]) . priestHit () ;
}
}

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.

Function creatureAttack ( team : Array ) : void
{
If ( ……… )
//Using it’s skill here
Else if ( ………… )
.
.
.
.
Else if ( ……….. )
//Using it’s own skill here
}
Function buildingAttack ( team : Array ) : void
{
….. //the same if-else clauses with different 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.

Var creatureAttack : AttackVisitor = new creatureAttack () ;
For ( var i : int = 0 ; I < team . length ; i ++ )
( teamElement ) team [ i ] . accept ( creatureAttack ) ;

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.

Function accept ( visitor : AttackVisitor ) : void
{
Visitor . visitElementX ( 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