The Contest
Okay, here’s a chance for Fame and Fortune. (We’ll supply the former; you supply the latter.) On Monday, April 27 you’ll find a new ActionScript 3.0 Easy and Practical Decorator Lunch Bucket Pattern on this blog. The contest will begin on Monday, April 27 and end Friday May, 22–2009. (That’s not a lot of time! But it should not take a lot of time to make the changes.) You can download the Decorator files here .
The contest is to see if you can change the Decorator design pattern in the new post, ActionScript 3.0 Easy and Practical Decorator Design Pattern.
Using the provided Component class (no changes allowed) and the provided Decorator class (no changes allowed) add new or changed Concrete Components and/or Concrete Decorators to make the most interesting program using the Decorator Design Pattern.
We have four age categories, and each category will have 1st, 2nd, and 3rd prizes. The Grand Prize will be given to the very best entry, regardless of age. Here are the categories:
- Under 18
- 18-25
- 26-40
- Over 40
All winners will be displayed on this blog along with their entries and photos. Read on to learn the rules.
The Rules
- You cannot change the code in the Component Class
- You cannot change the code in the Decorator Class
- You can only request concrete decorators or components from the Client class
- You cannot change the interfaces or signatures in the concrete decorator or component classes
- You cannot add bitmapped graphics or load external bitmapped or SWF files.
- You can add UI components to the Client class only and only for making requests for concrete decorators or components.
- All entries must be compacted in .zip format
- Either Adobe Flex Builder or Flash may be used—if it’s all code you could use Note Pad or TextEdit I suppose.
- All ActionScript must be version 3.0
If any of the rules are broken, the entry will be disqualified.
All inquiries about the Contest must be made to the Comments Section of this blog entry. The reason is that if one person has a query, there’s usually a dozen more with the same question, and it saves time to respond to a single query than many. (No email inquires will be answered).
All entries must have the following:
-
Name
Age
Subject Line in email: Golden Lunch Bucket Contest
Attached .zip file with your entry
Email entries to: Bill Sanders: wdsanders@comcast.net
No entries will be accepted after May 22, 2009
The ActionScript 3.0 Design Pattern Contest: The Golden Lunch Bucket Awards! by William B. Sanders, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
Bill Sanders
I’m confused about the goal of the competition. Is it to change the decorator pattern, as in make the pattern better? Or is it to make the most interesting application using solely the decorator pattern? or both?
Hi Nir,
The goal is to only change the content of the concrete classes. The point of the contest is to see how easy it is to make changes by changing only the concrete elements–either the concrete decorators or concrete components while maintaining the interfaces. I can imagine some very interesting things are possible.
The program itself will be posted on Monday. If you are in New Zealand, you’ll see it first.
Thanks for your interest!
Bill
How about FlashDevelop to compile? :)
So basically we can add more concrete decorators, and all we can do to the client is “wrap” the ui in them?
Thanks,
Josh
Hi Josh,
I know that FlashDevelop is popular (and has been recommended by some people I admire greatly), but for this contest, only Flex and Flash are allowed.
The Client (as always) is only for making requests, but the request process is greatly enhanced by a good UI, and so it makes sense to allow UI components for initiating requests.
You can add as many Concrete Components and Concrete Decorators as you like.
Looking forward to your entry,
Bill
I have a question about the decorator pattern itself. What if you want to extract one of the wraps from the list. On the fly, take out one of the dolls in the ‘Doll container of doll containers of doll containers’. What do you do then?
Hi Marcel,
If I’m not mistaken, you’re referring to Figure 4-2 on page 132 where we show a series of Russian dolls wrapping a concrete component. That’s an analogy, and keep in mind that the instantiation process in the Client does the work of “wrapping.” So if you want to change an object on the fly, simply remove the original one and re-wrap any concrete component in a different manner using whatever concrete decorators you wish to use.
However, what the main focus is on does not occur at runtime. Rather, if you want to change the program so that you have different concrete components or concrete decorators, they are easy to add, change or delete without disrupting the rest of the program.
Kindest regards,
Bill
I am confused. In the article “ActionScript 3.0 Easy and Practical Decorator Design Pattern” you elude to creating parameters for getFigure, but then say “However, the focus is on what the concrete decorators do and how they can be used as objects to change a concrete component; so for the time being don’t worry about adding parameters. (You can add parameters later.)” So are we not to add parameters to the concreteDecorators? We cannot change the code in the Component, so we cannot change the signature of the getFigure, so we cannot add any parameters. Correct? This seems really limiting, because then we are basically just drawing shapes with getFigure. We cannot add anything into the base Component, so we cannot do anything like add Text into the piece, because getFigure returns a Shape.
Hi Todd,
I see your point about mentioning parameters and then disallowing them in the contest. Sorry for the confusion.
Here’s the point. The purpose of the contest is not to re-write the decorator per se. Rather it is to focus on just those elements in the design that are meant to be changed. In the case of the Decorator pattern, the concrete components and decorators are the change elements. You can add more; keep the same ones and change them or some combination of the above. The purpose of all of the design patterns is to arrange the components so that change comes easily where you want it to come.
When you begin changing the signature, the effects ripple through the whole program, and that defeats the purpose of the pattern. You want to be able to change certain things without disrupting the entire program. Yes, I could have made a more complex signature that would have provided more runtime flexibility, but it would have been more difficult to understand for those who are just learning the Decorator for the first time. The Lunch Bucket examples on this blog are a combination of simplicity and practicality to reveal what the pattern is meant to do. If I err on the example, I tend to do so on the side of simplicity. That can be frustrating for some, but my hope is that a larger group of people will see possibilities beyond the example itself.
So, for now, all changes are to a Shape—any Shape— and in the concrete component or concrete decorator. Likewise, you can add more concrete components and concrete decorators. However, you’ve given me an idea for another post that deals with more sophisticated operations that might be added to concrete components and decorators.
Kindest regards,
Bill
Hey hey,
What if we want multiple of the same component? Creating duplicate concrete components just with different x,y co-ordinates doesn’t seem like good practice?
Thanks,
Josh
Thanks for that simplicity William. I am one of those learning, but I was just wondering about the parameters thing. It is mostly because of Josh’s post. I wanted to have the ability to put text out, and put a single concrete Decorator at multiple locations. But I am learning so thanks for the contest.
Hi Josh,
You can make as many instances as you want in the Client. Here’s a clue:
import flash.display.Shape;
——————
private var mover:Shape=new Shape();
——————
block = new ConcreteDecorator3(block);
addChild(block.getFigure());
mover = block.getFigure();
mover.x=-100, mover.y=10;
addChild(mover);
Take care,
Bill
Hi Todd,
You’ll have to forget the text for now; however, in looking at the reply to Josh’s query, you have the clue how to create lots of instances and move them around.
Best regards,
Bill
(BTW–It’s Bill — not William. I have to use the same name as the one on the book. However, it’s Bill.)
Oh ok,
I just thought we couldn’t modifiy the component at all from the client other than creating it.
Thanks for clearing that up,
Josh
Hi Josh,
The little example is to show how you could create a many instances of a concrete decorator as you want and move them so that you could position them in such a way that they would not be exactly in the same position. So, you really wouldn’t be modifying the concrete decorator; rather you’d be placing the results in another Shape instance in a different position.
Take care,
Bil
I think the clarity of the movement might have been lost because in the example the same circle was created in three different places (granted with different colors), but the places were done through the different drawing api locations.
However, that said, it is a contest and we could have come up with this on our own. Thanks for the helper code, it is clear.
Sorry, in a UI can we add text for scorekeeping for a game? It would’t be adding and removing items, but my decorator implementation is creating a game like scenario and I wanted to keep track of a score.
Gotcha, Obviously, this work is done with the client…and later in the examples the decorators are pushed into an array. Which are always easy to manipulate. Thanks for the clarity William. I’ve read the whole book but this book must be read at least 4 times for a tortoise like me.