I could take a stab at this :D
DEFINITION
A decorator (design pattern) provides extended functionality onto a class ("decorates") without the use of subclassing that specific class. It's pretty much an alternate method of creating a more specific class catered to the need at hand that is handled at runtime instead of at compile time (subclassing).
The benefit of this is that we don't have to create a large set of specific 'child' subclasses for every class of that type.
EXAMPLE
Well lets provide an example since that may have not made sense.
A cocos2d example for a decorator is CCSpeed. (there are others like easing actions, etc. but speed is probably easiest to understand)
CCSpeed allows us to affect the rate of duration of an action. (Changes its speed)
CCAction *move = [CCMoveBy actionWithDuration:1.f position:ccp(10,0)];
CCAction *speed =[CCSpeed actionWithAction:move rate:0.5f];
That code above changes our speed for the CCMoveby so it's duration is shorter (moves faster) and it does that at runtime.
NOT USING DECORATOR?
If we weren't using a decorator we would have subclassed CCMoveBy to CCSpeedMoveBy for the same effect.
// Alternate way with subclassing the child we want to modify
[CCSpeedMoveBy actionWithDuration:1.f position:ccp(10,0) rate:0.5f];
But since this is done at compile time we see how inefficient that is. We'd have to now go through every IntervalAction and apply this Speed subclassing just for everyone to gain this benefit.
ie: CCSpeedRotateBy, CCSpeedScaleBy, CCSpeedTintTo, CCSpeedJumpBy, CCSpeedBlink, CCSpeedFadeIn, etc...
You can see it get's really messy and if anyone else creates a new interval action they would have to create a speed subclass of that action too!
...
So here comes decorator to the rescue! CCSpeed is nice because as a decorator we get its benefit if we create new interval actions. We apply CCSpeed at runtime rather than compile time.
What's great about this is we can apply decorations on top of decorations without more subclassing. It get's long but it's not as messy as the subclassing attempt.
[CCSpeed actionWithAction:[CCSpeed actionWithAction:[CCSpeed actionWithAction:[CCSpeed actionWithAction:move rate:0.5f] rate:0.5f] rate:0.5f] rate:0.5f];
You wouldn't do what I did above but you would probably want to add CCSpeed with CCEaseActions or other actions that take an action as an argument.
Really all it does is enhance/modify/decorate/change the behavior of the original action.
BACK TO MODIFY TARGET ACTION
Ok so now for the ModifyTargetAction.
It's pretty much the same idea.
We want an action that is run on multiple sprites using runAction.
But... runAction ensures that the target is always the one calling the method.
// All the move actions target are referenced to self!
[self runAction:[CCSequence actions:move1,move2,move3,nil]];
So let's say we've implemented ModifyTargetAction. Then we can do this.
[self runAction:[CCSequence actions:[ModifyTargetAction actionWithNewTarget:sprite1 innerAction:move1], [ModifyTargetAction actionWithNewTarget:sprite2 innerAction:move2], nil]];
Wow that code above is kinda long but that's pretty much it!
Hope this loooong post is clear. If it's not just ask.
