: : S c h e l t e r S t u d i o s : :

So far things are working pretty well for the Decorator Demo I’ve posted a few days back. I have been adding bits and pieces to it, all the while gaining a better understanding of the power (and limitations) they possess. For those of you who don’t know, the Decorator Pattern is a famous pattern used to modify or stack logic to a pre-existing object on runtime. Since decorators and the core classes they decorate both share a common interface, you can “decorate” a class or an already-decorated class and still keep the same implementation within the application. In the case of my demo, a custom UIComponent I’ve named DummyStage holds all the dummy sprites and communicates to them, regardless of how many layers of decorators may be applied to them.

In my particular demonstration, there are two main methods from the IDummy interface that the stage uses to talk to the decorators/dummies on a regular basis. The first one, advance(), tells the decorator to perform its routine logic for “advancing” the dummy. A rotate modifier will increment the dummy’s rotation by 1 degree. A move modifier will shift the dummy by 1 pixel in the direction its facing. A doubler modifier will call the advance() method of the decorators inside it twice instead of once. For deflect and collision modifiers, however, the call is simply ignored and passed along, as they have no logic associated with advancing the dummy. Once the call path reaches the dummy itself, it dies.

After all the dummy’s advance calls are made, the stage then checks the status of the dummies to ensure that they aren’t going out of bounds. The checkBounds() method is called, which is immediately passed down by each decorator straight to the dummy. The dummy determines if a boundary has been breached, and returns a point indicating the deviation (if any) from the nearest desired position. The point then bubbles back up through return statements towards the stage. Along the way, however, collision modifiers will attempt to run a hit test against the other dummies, and alter the point value to account for any other collisions that may have occurred. Deflect modifiers also analyze the point to flip the rotation of the dummy based on its value before bubbling it back up. Once the point reaches the stage, the dummy is shifted based on the value of the point and proceeds on to the next dummy.

The diagram below represents a hypothetical decorator/dummy system and how it would handle the advance() and checkBounds() calls.

UPDATE:

I went ahead and uploaded the latest source of the project. I haven’t done any commenting in it, and I still plan to work on the DummyStage class in addition to a few more flex components, but the decorators seem to be pretty solid now, and that’s what we’re really interested in anyway, right?

UPDATE 2:

I’ve received a few responses suggesting that the zip I was providing was missing some content. I could’ve sworn it was working in the past, but regardless, I decided to generate a source view using Flex, making it cleaner for you all to look at. Check it out below:

view source